Re: [boinc_dev] Time for version 7.8.1?

2017-08-11 Thread Richard Haselgrove
I built from the v7.8.1 tag earlier today - successfully to binaries only (I 
don't have the tools to build the installer), with only the usual number of 
compiler warnings under VS2013.

I didn't have time to test it, because the build machine was busy with other 
work, but I intend to explore the issues we discussed in 
https://lists.ssl.berkeley.edu/pipermail/boinc_alpha/2017-July/021908.html 
('Starting BOINC from command line'), and see if I can reduce them down to an 
issue suitable for a bugfix now we've been alerted to the problem. 

On Friday, 11 August 2017, 22:54, David Anderson  
wrote:
 

  From looking at the VirtualBox change log,
it looks like 5.1.26 has a lot of bug fixes relative to 5.1.22.
I'll use it unless I hear otherwise.

-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-11 Thread David Anderson

From looking at the VirtualBox change log,
it looks like 5.1.26 has a lot of bug fixes relative to 5.1.22.
I'll use it unless I hear otherwise.

-- David
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-11 Thread David Anderson

I'm building a Win 7.8.1;
I backported only the GUI RPC-related changes,
because they fixed crashes that I personally saw.

In the meantime, VirtualBox has moved from 5.1.22 to 5.1.26.
Is there any reason to use the newer version?

-- David

On 8/3/2017 12:35 PM, Juha Sointusalo wrote:

On 2 August 2017 at 05:11, Charlie Fenton  wrote:


Are there any other changes in GIT master that should be ported into the
7.8 branch before we tag and build BOINC 7.8.1 and release it for alpha
testing?


This command lists commits that are in master but not in 7.8 branch,
ignoring Drupal commits:

git cherry -v  origin/client_release/7/7.8  master  | grep -viE -e drupal
-e "^-"

Of the listed commits, these look like they could/should be included in 7.8:

de26ed56746c0af95afe99c00b798b6d5384e84c Increase the number of use cases
file_size() works correctly, per JuhaSointusalo.
ff7633a65def104b81a82b839f98fbe4b383f42f client: fix bug in URL-escaping
that fails for non-ASCII chars
6c0a92d1b1eafbb6560157762a5d3a68f750379c Manager: code formatting; no
functional change
8b06de2d28cc4f6a43c4f090d0a56bbc2635741c change comment; not functional
change
824b3e76543b834ae912d47e3f11e21d73bb0380 Manager: don't crash if GUI RPC
returns empty reply
3a96e95d02c97c20779bcb783cd3a5177fe8d96d GUI RPC client: use std::string
instead of fixed-size buffer for requests
a91f4c64088e805702e446516e2abb1faff9dfb2 LIB: Prevent the possible issue of
dereferencing a NULL pointer.
13fbb84d7347befa11a391bd9ef795cc03742d87 Manager: get rid of out_of_range
exception and handle such situation in a more graceful way.

I'll let Christian comment on this:

16a13e7e32379fdf016028dc0b5fd56668fed539 Travis: use Trusty image and use
apg-get to install dependencies

I included commits that only change formatting and such so that the
difference between master and 7.8 stays smaller and adding other commits is
perhaps easier.

Then there is this:

a0a6881818215e7f389417d57521af6537c1989d Manager: Use wxHTMLWindow in task
property window
86468699f0f6c3442dd8f9935e06b02d8bf034fd Manager: Fix typo

When Rom was release manager new features were developed in release branch
which is IMHO totally wrong and I'm more than happy if those days are over.
But right now we don't yet have a stable release. So is 7.8 open for new
features or not? (I'd also like the feature to be changed a bit. I'll write
a comment later.)

Of the changes not yet even in master I'd like #1979 "client/lib: don't
flush stdout and stderr in main loop" and another PR which I'll make soon
to be included. I can live without the others.


Should the new keyword stuff be included in the 7.8.1 builds?


IMHO, as long as it can't be tested it has no place in any release, whether
the release is beta or stable.




Is anyone other than me still using VS 2010 for local Windows builds?


David uses VS2010. I may be wrong but I think at some point Rom tried using
VS2013 for building but the executables didn't run on XP and he went back
to VS2010.



Opinions? Thoughts?


 From my perspective the only change is disabling the version check at
Manager startup. There's some Mac changes too but I don't know about those.
So what would we be testing with 7.8.1? IMHO, the remaining parts of the
version check don't work properly and need fixing. Should we give Vitalii
more time to fix it or do you want to release a new version just because it
doesn't crash on host startup?

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-09 Thread Oliver Bock
Hi Filip,

On 08/08/17 17:15 , Filip Rydlo wrote:
> Hi, Oliver.
> Perfect explanation!   Thank You.  I am starting to
> understand  the differences  between GIT and SVN  - thanx to You ! :-)

You're welcome! I'm always glad to help.

Cheers,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-08 Thread Filip Rydlo
Hi, Oliver.
Perfect explanation!   Thank You.  I am starting to understand  the
differences  between GIT and SVN  - thanx to You ! :-)

*Namaste*
Filip





2017-08-04 13:11 GMT+02:00 Oliver Bock :

> On 04/08/17 11:54 , Charlie Fenton wrote:
> > Perhaps I'm not understanding what you meant by "contains", but if I
> > create a new branch named "newbranch" from an existing branch named
> > "oldbranch", then any commits made to oldbranch after that are not
> > included in a build I make using newbranch unless I specifically port
> > them over, such as by cherry picking them from oldbranch into
> > newbranch or by merging one branch into the other.
>
> That's correct.
>
> > As I
> > understand it, checking out a branch or tag simply "hides" from your
> > development tools anything that is not considered part of that branch
> > or tag, while "revealing" to your developer tools everything that is
> > considered part of the branch or tag.
>
> Correct.
>
> > This allows us to perform a build at any time from exactly the same
> > source files as were originally used to build the version represented
> > by the tag. And it allows us to build from a feature branch without
> > including subsequent changes made outside that branch, which can be
> > useful while developing a feature.
>
> Correct.
>
> > Since the client_release/7/7.8 branch was created from master and was
> > then immediately tagged as client_release/7/7.8.0, Richard is correct
> > that, as a result of the way the branch was created, all the Drupal
> > source code up to that time became available in the branch and under
> > that tag, along with everything else in master at that point. I
> > believe that is what he meant by "included".
>
> Yep, I just wanted to make sure that this part is clear. It could also
> have meant that he wondered why the Drupal stuff is included in a client
> branch/tag *at all*, as in SVN times one could have created a branch/tag
> by only copying the client-related parts of trunk. Hence my words
> "potential confusion".
>
> Best,
> Oliver
>
>
>
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Laurence Field

Hi David,

You can also modify the command prompt to show which branch you are in.

https://coderwall.com/p/fasnya/add-git-branch-name-to-bash-prompt

This is useful, even when not doing releases.

Cheers,

Laurence
On 04/08/17 21:17, David Anderson wrote:

Having the branch in a separate directory makes it easier
to keep track of what branch you're in.
That step is optional but Rom and I find it useful.
-- David



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread David Anderson

Having the branch in a separate directory makes it easier
to keep track of what branch you're in.
That step is optional but Rom and I find it useful.
-- David

On 8/4/2017 3:10 AM, Richard Haselgrove wrote:

In that case, the workflow document linked by David earlier - 
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains totally 
unnecessary extra work steps:

* Clone branch: clone ​https://github.com/boinc/boinc.git into new dir w/ 
version num
* Right-click on dir; switch to new branch
* set version numbers in
* /: configure.ac, version.h, version.h.in, version.log
* in version.h, version.h.in: comment out pre-release with C syntax
* android: TODO; Oliver: textual representation, numerical value (increment) in 
7.6, it's 146, so use 147
* commit
* create tag client_release/7.8/7.8.0
* git push, check "include tags"

The only reasons I can see for creating a new directory are:

To create clean build folders for the development tools to work in
To create an offsite archival backup in case of disaster

and both of those should be done *after* the version number updates and tagging 
have taken place.

 On Friday, 4 August 2017, 10:54, Charlie Fenton 
 wrote:
  


  Hi Oliver,

Perhaps I'm not understanding what you meant by "contains", but if I create a new branch named 
"newbranch" from an existing branch named "oldbranch", then any commits made to oldbranch 
after that are not included in a build I make using newbranch unless I specifically port them over, such as 
by cherry picking them from oldbranch into newbranch or by merging one branch into the other. Is that not so?

I agree that your local repository always does contain all commits made to all branches as of the last time 
you synced with the remote repository, so you can "check out" any branch or tag you wish. As I 
understand it, checking out a branch or tag simply "hides" from your development tools anything 
that is not considered part of that branch or tag, while "revealing" to your developer tools 
everything that is considered part of the branch or tag.

This allows us to perform a build at any time from exactly the same source 
files as were originally used to build the version represented by the tag. And 
it allows us to build from a feature branch without including subsequent 
changes made outside that branch, which can be useful while developing a 
feature.

Since the client_release/7/7.8 branch was created from master and was then immediately 
tagged as client_release/7/7.8.0, Richard is correct that, as a result of the way the 
branch was created, all the Drupal source code up to that time became available in the 
branch and under that tag, along with everything else in master at that point. I believe 
that is what he meant by "included".

Cheers,
--Charlie

On Aug 4, 2017, at 12:45 AM, Oliver Bock  wrote:

On 03/08/17 17:03 , Richard Haselgrove wrote:

it also means that the whole of the Drupal source code was included in the 
v7.8.0 'client' tag.

Just to avoid potential confusion: we're not using SVN anymore. A git
branch always "contains" the whole repo, not some copy of specific parts
of it.

Best,
Oliver


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.



___

boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 15:52 , Juha Sointusalo wrote:
> Oh but they are taken care of. They are ignored :/

Right, and that's perfectly fine for build artifacts. As we've seen the
root cause of the problem is the current build system, so that needs
fixing. Requiring everyone to use a fresh clone is a band-aid that's
bound to fail, not a solution.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Juha Sointusalo
On 4 August 2017 at 16:12, Oliver Bock  wrote:

> On 04/08/17 14:39 , Juha Sointusalo wrote:
> > I think there is one benefit from having a new, empty directory for
> > building release versions. You can be certain that the build will not
> > include files left over from previous development work.
>
> True, but that's why I recommended to actively manage your working tree
> which includes taking care of untracked files (see previous mail).
>

Oh but they are taken care of. They are ignored :/

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 14:39 , Juha Sointusalo wrote:
> I think there is one benefit from having a new, empty directory for
> building release versions. You can be certain that the build will not
> include files left over from previous development work.

True, but that's why I recommended to actively manage your working tree
which includes taking care of untracked files (see previous mail).

> BOINC's Unix
> build system has a bug that allows one to, for example, compile a new
> version of client and link it with an older version of libboinc. Been
> there, done that and it took a while to figure out while the client is
> crashing in a place where it possibly couldn't crash.

Good point, but it would be better to fix the root cause and not
navigate around the symptoms :-)

Cheers,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Juha Sointusalo
On 4 August 2017 at 14:31, Oliver Bock  wrote:

> On 04/08/17 12:10 , Richard Haselgrove wrote:
> > The only reasons I can see for creating a new directory are:
> > To create clean build folders for the development tools to work in
>
> Yes, but even that is not necessary.


I think there is one benefit from having a new, empty directory for
building release versions. You can be certain that the build will not
include files left over from previous development work. BOINC's Unix build
system has a bug that allows one to, for example, compile a new version of
client and link it with an older version of libboinc. Been there, done that
and it took a while to figure out while the client is crashing in a place
where it possibly couldn't crash.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 14:30 , Oliver Bock wrote:
> On 04/08/17 14:15 , Richard Haselgrove wrote:
>> Provided the local clone has "origin: master"?
> 
> A local clone has everything of the upstream repo (origin by default) at
> the time the clone occurred.

That said, even if you deleted "master" locally, you could still check
it out again (based on origin), even without the upstream remote being
available! The reason being that branches are just pointers to commit
objects. If you remove the "master" pointer the underlying data doesn't
vanish, in particular as long as other pointers like "origin/master"
still reference it.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 14:15 , Richard Haselgrove wrote:
> Provided the local clone has "origin: master"?

A local clone has everything of the upstream repo (origin by default) at
the time the clone occurred. To sync your local clone (the repo itself,
not its current working tree) with all remotes just run "git remote
update" for instance.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Juha Sointusalo
On 4 August 2017 at 14:53, Laurence  wrote:

> However the corresponding link for 7.8.1 does not exist
>
> https://github.com/BOINC/boinc/archive/client_release/7.1/7.8.1.tar.gz
>
> I would need this link so that I can start the Fedora build and test
> process.
>

7.8.1 doesn't exist yet. We are only discussing if we should have 7.8.1 and
what should be in it.

If you are going to build Linux release packages should you be listed
in Software
maintenance roles ?

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 14:17 , Oliver Bock wrote:
> If there would be the respective SHA1s couldn't
> be identical, right? :-)

As always in situations like this, let me share again my canonical
recommended reading (erm, viewing) on how git works:

https://vimeo.com/14629850
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

HTH,
Oliver




smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Richard Haselgrove
Provided the local clone has "origin: master"?
Which I take it, it should - unless you have a specific disentanglement task to 
perform. 

On Friday, 4 August 2017, 13:10, Vitalii Koshura 
 wrote:
 

 @Laurence,
>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?

Correct

Best regards,
Vitalii Koshura

2017-08-04 15:01 GMT+03:00 Laurence :

> Hi,
>
> On 04/08/17 13:31, Oliver Bock wrote:
>
>>
>> To create an offsite archival backup in case of disaster
>>>
>> No. If you want your local repo backed up, just push it to a remote of
>> your choice. Typically that's your personal fork on GitHub.
>>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?
>
> Cheers,
>
> Laurence
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 14:01 , Laurence wrote:
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?

Of course! All clones/forks are created equal. There's no qualitative
difference between them. If there would be the respective SHA1s couldn't
be identical, right? :-)

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Vitalii Koshura
@Laurence,
>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?

Correct

Best regards,
Vitalii Koshura

2017-08-04 15:01 GMT+03:00 Laurence :

> Hi,
>
> On 04/08/17 13:31, Oliver Bock wrote:
>
>>
>> To create an offsite archival backup in case of disaster
>>>
>> No. If you want your local repo backed up, just push it to a remote of
>> your choice. Typically that's your personal fork on GitHub.
>>
> Is my understanding correct that when we do git clone we get everything?
> This means that if github disappeared tomorrow, we could recreate the
> repository from anyone's local copy?
>
> Cheers,
>
> Laurence
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Laurence

Hi,

On 04/08/17 13:31, Oliver Bock wrote:



To create an offsite archival backup in case of disaster

No. If you want your local repo backed up, just push it to a remote of
your choice. Typically that's your personal fork on GitHub.
Is my understanding correct that when we do git clone we get everything? 
This means that if github disappeared tomorrow, we could recreate the 
repository from anyone's local copy?


Cheers,

Laurence
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Laurence

Hi,

On 04/08/17 11:52, Laurence wrote:


We should be targeting at least Debian and Fedora. I am in the 
processes of doing this.


Sorry for joining this conversation late.

For Fedora we were taking the code from the following URL

https://github.com/BOINC/boinc/archive/client_release/7.6/7.6.33.tar.gz

However the corresponding link for 7.8.1 does not exist

https://github.com/BOINC/boinc/archive/client_release/7.1/7.8.1.tar.gz

I would need this link so that I can start the Fedora build and test 
process.


Cheers,

Laurence

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 12:10 , Richard Haselgrove wrote:
> In that case, the workflow document linked by David earlier
> - https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains
> totally unnecessary extra work steps:

Indeed.

> * Clone branch: clone ​https://github.com/boinc/boinc.git into new dir
> w/ version num

The wording "clone branch" is at least confusing and even wrong when
read out of context. The line is incomplete and inconsistent.

Also, using TortoiseGit (being a Windows Explorer context menu
extension) as the canonical example isn't a good choice. One should use
platform independent descriptions that help everyone. The git CLI or
even GUIs like GitKraken and SourceTree are certainly better suited for
that purpose.

But first things first. These issues can be addressed in a general overhaul.

> * android: TODO; Oliver: textual representation, numerical value (increment) 
> in 7.6, it's 146, so use 147
FYI, that's already been taken care of (for Android at least) via:
https://github.com/BOINC/boinc/issues/1864

The desktop manager's still pending though.

> The only reasons I can see for creating a new directory are:
> To create clean build folders for the development tools to work in

Yes, but even that is not necessary. You can (and should) always check
for and handle untracked files using "git status" (ignore or add them).
You may also stash away pending working tree changes using "git stash".
Working in multiple copies of a repo can be more confusing to beginners
than sticking to a single one that's properly managed.

> To create an offsite archival backup in case of disaster

No. If you want your local repo backed up, just push it to a remote of
your choice. Typically that's your personal fork on GitHub.

Cheers,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 11:54 , Charlie Fenton wrote:
> Perhaps I'm not understanding what you meant by "contains", but if I
> create a new branch named "newbranch" from an existing branch named
> "oldbranch", then any commits made to oldbranch after that are not
> included in a build I make using newbranch unless I specifically port
> them over, such as by cherry picking them from oldbranch into
> newbranch or by merging one branch into the other.

That's correct.

> As I
> understand it, checking out a branch or tag simply "hides" from your
> development tools anything that is not considered part of that branch
> or tag, while "revealing" to your developer tools everything that is
> considered part of the branch or tag.

Correct.

> This allows us to perform a build at any time from exactly the same
> source files as were originally used to build the version represented
> by the tag. And it allows us to build from a feature branch without
> including subsequent changes made outside that branch, which can be
> useful while developing a feature.

Correct.

> Since the client_release/7/7.8 branch was created from master and was
> then immediately tagged as client_release/7/7.8.0, Richard is correct
> that, as a result of the way the branch was created, all the Drupal
> source code up to that time became available in the branch and under
> that tag, along with everything else in master at that point. I
> believe that is what he meant by "included".

Yep, I just wanted to make sure that this part is clear. It could also
have meant that he wondered why the Drupal stuff is included in a client
branch/tag *at all*, as in SVN times one could have created a branch/tag
by only copying the client-related parts of trunk. Hence my words
"potential confusion".

Best,
Oliver





smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Richard Haselgrove
In that case, the workflow document linked by David earlier - 
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains totally 
unnecessary extra work steps:

* Clone branch: clone ​https://github.com/boinc/boinc.git into new dir w/ 
version num
* Right-click on dir; switch to new branch
* set version numbers in
* /: configure.ac, version.h, version.h.in, version.log
* in version.h, version.h.in: comment out pre-release with C syntax
* android: TODO; Oliver: textual representation, numerical value (increment) in 
7.6, it's 146, so use 147
* commit
* create tag client_release/7.8/7.8.0
* git push, check "include tags"

The only reasons I can see for creating a new directory are:

To create clean build folders for the development tools to work in
To create an offsite archival backup in case of disaster

and both of those should be done *after* the version number updates and tagging 
have taken place. 

On Friday, 4 August 2017, 10:54, Charlie Fenton  
wrote:
 

 Hi Oliver,

Perhaps I'm not understanding what you meant by "contains", but if I create a 
new branch named "newbranch" from an existing branch named "oldbranch", then 
any commits made to oldbranch after that are not included in a build I make 
using newbranch unless I specifically port them over, such as by cherry picking 
them from oldbranch into newbranch or by merging one branch into the other. Is 
that not so?

I agree that your local repository always does contain all commits made to all 
branches as of the last time you synced with the remote repository, so you can 
"check out" any branch or tag you wish. As I understand it, checking out a 
branch or tag simply "hides" from your development tools anything that is not 
considered part of that branch or tag, while "revealing" to your developer 
tools everything that is considered part of the branch or tag. 

This allows us to perform a build at any time from exactly the same source 
files as were originally used to build the version represented by the tag. And 
it allows us to build from a feature branch without including subsequent 
changes made outside that branch, which can be useful while developing a 
feature.

Since the client_release/7/7.8 branch was created from master and was then 
immediately tagged as client_release/7/7.8.0, Richard is correct that, as a 
result of the way the branch was created, all the Drupal source code up to that 
time became available in the branch and under that tag, along with everything 
else in master at that point. I believe that is what he meant by "included".

Cheers,
--Charlie

On Aug 4, 2017, at 12:45 AM, Oliver Bock  wrote:
> On 03/08/17 17:03 , Richard Haselgrove wrote:
>> it also means that the whole of the Drupal source code was included in the 
>> v7.8.0 'client' tag.
> 
> Just to avoid potential confusion: we're not using SVN anymore. A git
> branch always "contains" the whole repo, not some copy of specific parts
> of it.
> 
> Best,
> Oliver
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Charlie Fenton
Hi Oliver,

Perhaps I'm not understanding what you meant by "contains", but if I create a 
new branch named "newbranch" from an existing branch named "oldbranch", then 
any commits made to oldbranch after that are not included in a build I make 
using newbranch unless I specifically port them over, such as by cherry picking 
them from oldbranch into newbranch or by merging one branch into the other. Is 
that not so?

I agree that your local repository always does contain all commits made to all 
branches as of the last time you synced with the remote repository, so you can 
"check out" any branch or tag you wish. As I understand it, checking out a 
branch or tag simply "hides" from your development tools anything that is not 
considered part of that branch or tag, while "revealing" to your developer 
tools everything that is considered part of the branch or tag. 

This allows us to perform a build at any time from exactly the same source 
files as were originally used to build the version represented by the tag. And 
it allows us to build from a feature branch without including subsequent 
changes made outside that branch, which can be useful while developing a 
feature.

Since the client_release/7/7.8 branch was created from master and was then 
immediately tagged as client_release/7/7.8.0, Richard is correct that, as a 
result of the way the branch was created, all the Drupal source code up to that 
time became available in the branch and under that tag, along with everything 
else in master at that point. I believe that is what he meant by "included".

Cheers,
--Charlie

On Aug 4, 2017, at 12:45 AM, Oliver Bock  wrote:
> On 03/08/17 17:03 , Richard Haselgrove wrote:
>> it also means that the whole of the Drupal source code was included in the 
>> v7.8.0 'client' tag.
> 
> Just to avoid potential confusion: we're not using SVN anymore. A git
> branch always "contains" the whole repo, not some copy of specific parts
> of it.
> 
> Best,
> Oliver
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Laurence


On 03/08/17 23:21, Juha Sointusalo wrote:

There's also the matter of Linux version which doesn't exists at the
moment. There's one user who compiled 7.8.0 himself and immediately found
two bugs in it.
http://boinc.berkeley.edu/dev/forum_thread.php?id=11719=79576
(Although the bugs existed in earlier releases too.)

Christian has some reservations against building a version that targets a
recent Ubuntu. But I think that until there is something better then one
that targets Ubuntu is better than nothing. If nothing else maybe it'll
send a signal to other distro users that it's time to start testing again.
We should be targeting at least Debian and Fedora. I am in the processes 
of doing this.


Cheers,

Laurence
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 10:55 , Richard Haselgrove wrote:
> I think those last two messages expose the nub of the confusion. Are
> we, or are we not

Yep.

> using Git in the way that Git was designed to be used?

Git is just a tool, not a process. It wasn't designed to be used in one
specific way. It makes possible and facilitates new improved ways to do
software configuration management. Once you settle on your tailored
process (hopefully based on widely accepted best practices) you
implement it as a workflow - git then lets you carry it out effectively
and efficiently.

> Oliver, have you reviewed the release management paper that David has
> just linked?

Yes. I agree with some parts and I disagree with some parts. Fortunately
it's likely to be revised soon. I *described the reasons* why the
process needs to change a number of times on this channel and, sorry,
I'm getting tired of repeating myself over and over again. Just see the
2-3 keywords threads to get an idea. Some of the reasons can also be
read here:

https://github.com/BOINC/boinc/issues/1874


Cheers,
Oliver




smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Richard Haselgrove
I think those last two messages expose the nub of the confusion. Are we, or are 
we not, using Git in the way that Git was designed to be used?
Oliver, have you reviewed the release management paper that David has just 
linked? 

On Friday, 4 August 2017, 9:50, David Anderson  
wrote:
 

 
On 8/4/2017 1:41 AM, Oliver Bock wrote:
> hype, but because of its blatant advantages for what we do. Sadly BOINC
> is still barely making use of it.
Actually we are.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread David Anderson


On 8/4/2017 1:41 AM, Oliver Bock wrote:

hype, but because of its blatant advantages for what we do. Sadly BOINC
is still barely making use of it.

Actually we are.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Oliver Bock
On 04/08/17 9:58 , Richard Haselgrove wrote:
> Is there also a change in the definition of a 'tag'? In SVN days, a tag
> - which we used to identify client code, nothing else - included only:

A git tag is just a label you stick on a given commit. Nothing more,
nothing less. How you use them is up to you. If you tag a client version
then you just express which state of the (whole) repo was used to build
it. That's all. That said, it's (normally) irrelevant for the client
build what Drupal-related code was in the repo at build time. However,
other components might indeed have an (unknown side-) effect on the
client build so it's actually a huge advantage to know the state of the
whole repo at the time of the build.

There are a lot of "Git for SVN users" tutorials out there. Just have a
look if you're curious. We migrated from SVN to git not just for the
hype, but because of its blatant advantages for what we do. Sadly BOINC
is still barely making use of it.

HTH,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread David Anderson

Branches and tags are different things in git.
The release process is described here:
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement

-- David

On 8/4/2017 12:58 AM, Richard Haselgrove wrote:

Indeed. I'm slowly getting my head round the other differences that affect our 
workflow.

Is there also a change in the definition of a 'tag'? In SVN days, a tag - which 
we used to identify client code, nothing else - included only:

code which was used to build the client-related parts
code which Rom deemed fit and ready for use

If that selectivity is no longer available, does that mean we have to be 
careful to clear all client-related issues and bugs, before the 'tag-and-build' 
process for the next release? That we can't leave behind any unfinished 
business for the next cycle?

 On Friday, 4 August 2017, 8:45, Oliver Bock  wrote:
  


  On 03/08/17 17:03 , Richard Haselgrove wrote:

it also means that the whole of the Drupal source code was included in the 
v7.8.0 'client' tag.

Just to avoid potential confusion: we're not using SVN anymore. A git
branch always "contains" the whole repo, not some copy of specific parts
of it.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___

boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-04 Thread Richard Haselgrove
Indeed. I'm slowly getting my head round the other differences that affect our 
workflow.

Is there also a change in the definition of a 'tag'? In SVN days, a tag - which 
we used to identify client code, nothing else - included only:

code which was used to build the client-related parts
code which Rom deemed fit and ready for use

If that selectivity is no longer available, does that mean we have to be 
careful to clear all client-related issues and bugs, before the 'tag-and-build' 
process for the next release? That we can't leave behind any unfinished 
business for the next cycle? 

On Friday, 4 August 2017, 8:45, Oliver Bock  wrote:
 

 On 03/08/17 17:03 , Richard Haselgrove wrote:
> it also means that the whole of the Drupal source code was included in the 
> v7.8.0 'client' tag.

Just to avoid potential confusion: we're not using SVN anymore. A git
branch always "contains" the whole repo, not some copy of specific parts
of it.

Best,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

   
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Juha Sointusalo
There's also the matter of Linux version which doesn't exists at the
moment. There's one user who compiled 7.8.0 himself and immediately found
two bugs in it.
http://boinc.berkeley.edu/dev/forum_thread.php?id=11719=79576
(Although the bugs existed in earlier releases too.)

Christian has some reservations against building a version that targets a
recent Ubuntu. But I think that until there is something better then one
that targets Ubuntu is better than nothing. If nothing else maybe it'll
send a signal to other distro users that it's time to start testing again.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Juha Sointusalo
On 3 August 2017 at 23:17, Vitalii Koshura 
wrote:

> I guess it would be better to release without new version check because
> now I'm making some changes around this and I'm realising that it would be
> better to make this feature if a different way and this will require
> changes on both client and manager side. And this should be written and
> tested very carefully.
>

Do you think if it would be better to just revert the feature and retry it
for v8?

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Vitalii Koshura
Hello Juha,

I guess it would be better to release without new version check because now
I'm making some changes around this and I'm realising that it would be
better to make this feature if a different way and this will require
changes on both client and manager side. And this should be written and
tested very carefully.

Thanks

Best regards,
Vitalii Koshura

2017-08-03 22:35 GMT+03:00 Juha Sointusalo :

> On 2 August 2017 at 05:11, Charlie Fenton 
> wrote:
>
> > Are there any other changes in GIT master that should be ported into the
> > 7.8 branch before we tag and build BOINC 7.8.1 and release it for alpha
> > testing?
>
>
> This command lists commits that are in master but not in 7.8 branch,
> ignoring Drupal commits:
>
> git cherry -v  origin/client_release/7/7.8  master  | grep -viE -e drupal
> -e "^-"
>
> Of the listed commits, these look like they could/should be included in
> 7.8:
>
> de26ed56746c0af95afe99c00b798b6d5384e84c Increase the number of use cases
> file_size() works correctly, per JuhaSointusalo.
> ff7633a65def104b81a82b839f98fbe4b383f42f client: fix bug in URL-escaping
> that fails for non-ASCII chars
> 6c0a92d1b1eafbb6560157762a5d3a68f750379c Manager: code formatting; no
> functional change
> 8b06de2d28cc4f6a43c4f090d0a56bbc2635741c change comment; not functional
> change
> 824b3e76543b834ae912d47e3f11e21d73bb0380 Manager: don't crash if GUI RPC
> returns empty reply
> 3a96e95d02c97c20779bcb783cd3a5177fe8d96d GUI RPC client: use std::string
> instead of fixed-size buffer for requests
> a91f4c64088e805702e446516e2abb1faff9dfb2 LIB: Prevent the possible issue
> of
> dereferencing a NULL pointer.
> 13fbb84d7347befa11a391bd9ef795cc03742d87 Manager: get rid of out_of_range
> exception and handle such situation in a more graceful way.
>
> I'll let Christian comment on this:
>
> 16a13e7e32379fdf016028dc0b5fd56668fed539 Travis: use Trusty image and use
> apg-get to install dependencies
>
> I included commits that only change formatting and such so that the
> difference between master and 7.8 stays smaller and adding other commits is
> perhaps easier.
>
> Then there is this:
>
> a0a6881818215e7f389417d57521af6537c1989d Manager: Use wxHTMLWindow in task
> property window
> 86468699f0f6c3442dd8f9935e06b02d8bf034fd Manager: Fix typo
>
> When Rom was release manager new features were developed in release branch
> which is IMHO totally wrong and I'm more than happy if those days are over.
> But right now we don't yet have a stable release. So is 7.8 open for new
> features or not? (I'd also like the feature to be changed a bit. I'll write
> a comment later.)
>
> Of the changes not yet even in master I'd like #1979 "client/lib: don't
> flush stdout and stderr in main loop" and another PR which I'll make soon
> to be included. I can live without the others.
>
>
> Should the new keyword stuff be included in the 7.8.1 builds?
>
>
> IMHO, as long as it can't be tested it has no place in any release, whether
> the release is beta or stable.
>
>
>
> > Is anyone other than me still using VS 2010 for local Windows builds?
> >
>
> David uses VS2010. I may be wrong but I think at some point Rom tried using
> VS2013 for building but the executables didn't run on XP and he went back
> to VS2010.
>
>
> > Opinions? Thoughts?
> >
>
> From my perspective the only change is disabling the version check at
> Manager startup. There's some Mac changes too but I don't know about those.
> So what would we be testing with 7.8.1? IMHO, the remaining parts of the
> version check don't work properly and need fixing. Should we give Vitalii
> more time to fix it or do you want to release a new version just because it
> doesn't crash on host startup?
>
> -Juha
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Juha Sointusalo
On 3 August 2017 at 22:35, Juha Sointusalo 
wrote:

> and another PR which I'll make soon
>

And that became #2008 "lib: fix boinc_file_exists() on Windows".

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Juha Sointusalo
On 2 August 2017 at 05:11, Charlie Fenton  wrote:

> Are there any other changes in GIT master that should be ported into the
> 7.8 branch before we tag and build BOINC 7.8.1 and release it for alpha
> testing?


This command lists commits that are in master but not in 7.8 branch,
ignoring Drupal commits:

git cherry -v  origin/client_release/7/7.8  master  | grep -viE -e drupal
-e "^-"

Of the listed commits, these look like they could/should be included in 7.8:

de26ed56746c0af95afe99c00b798b6d5384e84c Increase the number of use cases
file_size() works correctly, per JuhaSointusalo.
ff7633a65def104b81a82b839f98fbe4b383f42f client: fix bug in URL-escaping
that fails for non-ASCII chars
6c0a92d1b1eafbb6560157762a5d3a68f750379c Manager: code formatting; no
functional change
8b06de2d28cc4f6a43c4f090d0a56bbc2635741c change comment; not functional
change
824b3e76543b834ae912d47e3f11e21d73bb0380 Manager: don't crash if GUI RPC
returns empty reply
3a96e95d02c97c20779bcb783cd3a5177fe8d96d GUI RPC client: use std::string
instead of fixed-size buffer for requests
a91f4c64088e805702e446516e2abb1faff9dfb2 LIB: Prevent the possible issue of
dereferencing a NULL pointer.
13fbb84d7347befa11a391bd9ef795cc03742d87 Manager: get rid of out_of_range
exception and handle such situation in a more graceful way.

I'll let Christian comment on this:

16a13e7e32379fdf016028dc0b5fd56668fed539 Travis: use Trusty image and use
apg-get to install dependencies

I included commits that only change formatting and such so that the
difference between master and 7.8 stays smaller and adding other commits is
perhaps easier.

Then there is this:

a0a6881818215e7f389417d57521af6537c1989d Manager: Use wxHTMLWindow in task
property window
86468699f0f6c3442dd8f9935e06b02d8bf034fd Manager: Fix typo

When Rom was release manager new features were developed in release branch
which is IMHO totally wrong and I'm more than happy if those days are over.
But right now we don't yet have a stable release. So is 7.8 open for new
features or not? (I'd also like the feature to be changed a bit. I'll write
a comment later.)

Of the changes not yet even in master I'd like #1979 "client/lib: don't
flush stdout and stderr in main loop" and another PR which I'll make soon
to be included. I can live without the others.


Should the new keyword stuff be included in the 7.8.1 builds?


IMHO, as long as it can't be tested it has no place in any release, whether
the release is beta or stable.



> Is anyone other than me still using VS 2010 for local Windows builds?
>

David uses VS2010. I may be wrong but I think at some point Rom tried using
VS2013 for building but the executables didn't run on XP and he went back
to VS2010.


> Opinions? Thoughts?
>

>From my perspective the only change is disabling the version check at
Manager startup. There's some Mac changes too but I don't know about those.
So what would we be testing with 7.8.1? IMHO, the remaining parts of the
version check don't work properly and need fixing. Should we give Vitalii
more time to fix it or do you want to release a new version just because it
doesn't crash on host startup?

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Richard Haselgrove
I was using "git show" yesterday to find out how David had made the v7.8.0 tag 
(and how Rom had made the v7.6.33 tag, come to that). Both outputs attached: it 
appears that some sort of script was used. That sort of rules out Rom's old 
cherrypicking of individual commits: it also means that the whole of the Drupal 
source code was included in the v7.8.0 'client' tag.
I was looking because I was worried that a wholesale tagging might incorporate 
commits which Rom might have deliberately excluded - with unexpected effects 
that might need to be specially tested for. But I think that if that was going 
to happen, it probably happened well before v7.6.33, and we survived the 
experience. 

On Thursday, 3 August 2017, 15:38, Charlie Fenton 
 wrote:
 

 I almost forget: I believe that the translations need to be updated in the 7.8 
branch before tagging 7.8.1. 

@Christian: Can you take care of this? I believe you have been working on the 
Transifex stuff. 

Cheers,
--Charlie

On Aug 1, 2017, at 7:11 PM, Charlie Fenton  wrote:
> I just merged my July 21 fix for the Windows 10 Manager crashes into the 
> client_release/7/7.8 branch. If we want to get a new public version released, 
> we need to keep moving alpha testing forward. 
> 
> Are there any other changes in GIT master that should be ported into the 7.8 
> branch before we tag and build BOINC 7.8.1 and release it for alpha testing? 
> (The way Rom and I have always ported individual commits is to cherry pick 
> from master into the 7.8 branch.)
> 
> Should the new keyword stuff be included in the 7.8.1 builds? If so, it is 
> important that the Windows projects be updated for all supported versions of 
> Visual Studio and ported to the 7.8 branch before tagging 7.8.1, as well as 
> my commits 039fd90 (7/16/17) and 11b6ccc (7/31/17). Is anyone other than me 
> still using VS 2010 for local Windows builds?
> 
> Opinions? Thoughts? Volunteers to do the porting and tagging?
> 
> Cheers,
> --Charlie
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


   commit 3e6998e7cef71d2042c2b6585db51d2ed5d8ada2
Author: David Anderson 
Date:   Sun Jun 18 15:22:59 2017 -0700

update version #s, create tag client_release/7.8/7.8.0

diff --git a/configure.ac b/configure.ac
index e7d8e00..16b702d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ dnl not sure exactly what the minimum version is (but 2.13 wont 
work)
 AC_PREREQ(2.58)
 
 dnl Set the BOINC version here.  You can also use the set-version script.
-AC_INIT(BOINC, 7.7.0)
+AC_INIT(BOINC, 7.8.0)
 AC_CONFIG_MACRO_DIR([m4])
 LIBBOINC_VERSION=`echo ${PACKAGE_VERSION} | sed 's/\./:/g'`
 AC_SUBST([LIBBOINC_VERSION])
diff --git a/version.h b/version.h
index d8ef9cb..0d94688 100644
--- a/version.h
+++ b/version.h
@@ -7,10 +7,10 @@
 #define BOINC_MAJOR_VERSION 7
 
 /* Minor part of BOINC version number */
-#define BOINC_MINOR_VERSION 7
+#define BOINC_MINOR_VERSION 8
 
 /* Release part of BOINC version number */
-#define BOINC_RELEASE 2
+#define BOINC_RELEASE 0
 
 /* Release part of wrapper version number */
 #define WRAPPER_RELEASE 26016
@@ -19,10 +19,10 @@
 #define VBOXWRAPPER_RELEASE 26197
 
 /* String representation of BOINC version number */
-#define BOINC_VERSION_STRING "7.7.2"
+#define BOINC_VERSION_STRING "7.8.0"
 
 /* Package is a pre-release (Alpha/Beta) package */
-#define BOINC_PRERELEASE 1
+/* #define BOINC_PRERELEASE 1 */
 
 #if (defined(_WIN32) || defined(__APPLE__))
 /* Name of package */
@@ -35,13 +35,13 @@
 #define PACKAGE_NAME "BOINC"
 
 /* Define to the full name and version of this package. */
-#define PACKAGE_STRING "BOINC 7.7.2"
+#define PACKAGE_STRING "BOINC 7.8.0"
 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "boinc"
 
 /* Define to the version of this package. */
-#define PACKAGE_VERSION "7.7.2"
+#define PACKAGE_VERSION "7.8.0"
 
 #endif /* #if (defined(_WIN32) || defined(__APPLE__)) */
 
diff --git a/version.h.in b/version.h.in
index bc0e367..feefc44 100644
--- a/version.h.in
+++ b/version.h.in
@@ -22,7 +22,7 @@
 #define BOINC_VERSION_STRING "@BOINC_VERSION_STRING@"
 
 /* Package is a pre-release (Alpha/Beta) package */
-#define BOINC_PRERELEASE 1
+/* #define BOINC_PRERELEASE 1 */
 
 #if (defined(_WIN32) || defined(__APPLE__))
 /* Name of package */
diff --git a/version.log b/version.log
index 18bb418..09a6d30 100644
--- a/version.log
+++ b/version.log
@@ -1 +1 @@
-7.5.0
+7.8.0
commit 6f6c8b7eb5a3066171757ef162d72ca084cd3230
Author: Rom Walton 
Date:   Sun Jun 5 12:39:54 2016 -0700

- Tag for 7.6.33 release
client_release/7.6/7.6.33

diff --git a/android/BOINC/AndroidManifest.xml 
b/android/BOINC/AndroidManifest.xml
index 363b4b1..07f93aa 

Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Vitalii Koshura
@Charlie, we have two separate solution: first one for VS 2010 and second
one for VS 2013.
I think it would be better to mark VS 2010 as obsolete and remove it from
master forever. As far as I know David P. Anderson still use VS 2010 for
development. VS 2013 can be potentially upgraded to VS 2015 or VS 2017 but
we have two problems:
1 - Windows pre-built thirdparty components should be rebuilt with new
version too (VS 2015 or VS 2017). The only one person who can do this (as
far as I know) is Rom. Also he is probably the only one who have the
complete sources of those components. I can do this job (update third-party
sources to newer versions and build with the needed version of VS (I have
VS 2013, VS 2015, VS 2017 installed) but we need to decide where we can
store these binaries (existing git repo is not good because it is too big
now, some ftp or public cloud will be probably better).
2 - I tried to build BOINC using VS 2015 and got several compilation
errors. I can handle them but just let you know that just upgrade will lead
to broken build.

Thanks

Best regards,
Vitalii Koshura

2017-08-02 5:16 GMT+03:00 Charlie Fenton :

> I almost forget: I believe that the translations need to be updated in the
> 7.8 branch before tagging 7.8.1.
>
> @Christian: Can you take care of this? I believe you have been working on
> the Transifex stuff.
>
> Cheers,
> --Charlie
>
> On Aug 1, 2017, at 7:11 PM, Charlie Fenton 
> wrote:
> > I just merged my July 21 fix for the Windows 10 Manager crashes into the
> client_release/7/7.8 branch. If we want to get a new public version
> released, we need to keep moving alpha testing forward.
> >
> > Are there any other changes in GIT master that should be ported into the
> 7.8 branch before we tag and build BOINC 7.8.1 and release it for alpha
> testing? (The way Rom and I have always ported individual commits is to
> cherry pick from master into the 7.8 branch.)
> >
> > Should the new keyword stuff be included in the 7.8.1 builds? If so, it
> is important that the Windows projects be updated for all supported
> versions of Visual Studio and ported to the 7.8 branch before tagging
> 7.8.1, as well as my commits 039fd90 (7/16/17) and 11b6ccc (7/31/17). Is
> anyone other than me still using VS 2010 for local Windows builds?
> >
> > Opinions? Thoughts? Volunteers to do the porting and tagging?
> >
> > Cheers,
> > --Charlie
> >
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Charlie Fenton
I almost forget: I believe that the translations need to be updated in the 7.8 
branch before tagging 7.8.1. 

@Christian: Can you take care of this? I believe you have been working on the 
Transifex stuff. 

Cheers,
--Charlie

On Aug 1, 2017, at 7:11 PM, Charlie Fenton  wrote:
> I just merged my July 21 fix for the Windows 10 Manager crashes into the 
> client_release/7/7.8 branch. If we want to get a new public version released, 
> we need to keep moving alpha testing forward. 
> 
> Are there any other changes in GIT master that should be ported into the 7.8 
> branch before we tag and build BOINC 7.8.1 and release it for alpha testing? 
> (The way Rom and I have always ported individual commits is to cherry pick 
> from master into the 7.8 branch.)
> 
> Should the new keyword stuff be included in the 7.8.1 builds? If so, it is 
> important that the Windows projects be updated for all supported versions of 
> Visual Studio and ported to the 7.8 branch before tagging 7.8.1, as well as 
> my commits 039fd90 (7/16/17) and 11b6ccc (7/31/17). Is anyone other than me 
> still using VS 2010 for local Windows builds?
> 
> Opinions? Thoughts? Volunteers to do the porting and tagging?
> 
> Cheers,
> --Charlie
> 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


[boinc_dev] Time for version 7.8.1?

2017-08-03 Thread Charlie Fenton
I just merged my July 21 fix for the Windows 10 Manager crashes into the 
client_release/7/7.8 branch. If we want to get a new public version released, 
we need to keep moving alpha testing forward. 

Are there any other changes in GIT master that should be ported into the 7.8 
branch before we tag and build BOINC 7.8.1 and release it for alpha testing? 
(The way Rom and I have always ported individual commits is to cherry pick from 
master into the 7.8 branch.)

Should the new keyword stuff be included in the 7.8.1 builds? If so, it is 
important that the Windows projects be updated for all supported versions of 
Visual Studio and ported to the 7.8 branch before tagging 7.8.1, as well as my 
commits 039fd90 (7/16/17) and 11b6ccc (7/31/17). Is anyone other than me still 
using VS 2010 for local Windows builds?

Opinions? Thoughts? Volunteers to do the porting and tagging?

Cheers,
--Charlie

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.