Re: [boinc_dev] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[Nicolás Alvarez]

2017-03-29 14:45 GMT-03:00 Andy Bowery :
> Hi,
>
> We would be interested in an additional BOINC preference, a tickbox on the 
> 'Network' tab, with something like 'Download only when connected to a high 
> bandwidth connection'. Ticking the box of this preference would prevent 
> download of the application and supporting files when the machine (for 
> example: a laptop) was connected only to WiFi and not connected to a higher 
> bandwidth networking cable. Would it be possible for this to be scheduled to 
> be added as an item to be included in a later release?
>
> With regards,
>

What does "high bandwidth connection" mean, how could BOINC know if
it's connected to one?

-- 
Nicolás
___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Christian Beer]

On 29.03.2017 18:12, Jord van der Elst wrote:
>
> On Wed, Mar 29, 2017 at 5:59 PM, Christian Beer
> > wrote:
>
>
> Restricting to commits that have "client" in the commit title is also
> wrong as there is no commit discipline in BOINC (aka. no atomic
> commits)
> and you can have client changes embedded in other commits (where the
> message doesn't state that). You would need to at least include commit
> titles with "lib" too and that would probably still miss a lot of
> changes. You would need to restrict to commits that changed files in
> client/, clientgui/ and lib/.
>
>
> It was an example, Christian.
> For what matters, I now filter on client, mgr, mac, lib, scr,
> winbuild, locale, curl, openssl, zlib, linux, vbox and for
> completeness, server. Just because all of those at times make up a
> working client. 

And you are still missing the commits that do not state the component in
the title. You would need to better use everything except "locale"
changes. As Oliver also said in an earlier email the level of details of
a changelog is different for each audience. The normal user who wants to
decide if he needs to upgrade, only needs a summary of changes in plain
english. The developer who wants to fix stuff needs the complete commits
including the technical comments in the messages. By providing proper
tags to the repository each developer can create this complete change
log on the fly individually. The Changelog that the user of the software
sees needs to be created by hand. On other Open Source projects this is
done during development by setting version Milestones and every new
feature or change in behavior gets an issue and every commit is linked
to an issue. The list of commits are for the developers to look at. The
list of issues of a milestone can be compiled into a user-friendly
changelog (almost on the fly). A milestone represents the features or
changes that happened (or should happen) since the last milestone. It
would save a lot of work if BOINC would use a scheme like that.

Regards
Christian

___
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] An additional preference to prevent downloading when on WiFi, to enable downloading only on when connected to cable

[Andy Bowery]

Hi,

We would be interested in an additional BOINC preference, a tickbox on the 
'Network' tab, with something like 'Download only when connected to a high 
bandwidth connection'. Ticking the box of this preference would prevent 
download of the application and supporting files when the machine (for example: 
a laptop) was connected only to WiFi and not connected to a higher bandwidth 
networking cable. Would it be possible for this to be scheduled to be added as 
an item to be included in a later release?

With regards,

Andy

Oxford e-Research Centre
University of Oxford
7 Keble Road, Oxford, OX1 3QG

www.oerc.ox.ac.uk
___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Jord van der Elst]

On Wed, Mar 29, 2017 at 5:59 PM, Christian Beer 
wrote:

>
> Restricting to commits that have "client" in the commit title is also
> wrong as there is no commit discipline in BOINC (aka. no atomic commits)
> and you can have client changes embedded in other commits (where the
> message doesn't state that). You would need to at least include commit
> titles with "lib" too and that would probably still miss a lot of
> changes. You would need to restrict to commits that changed files in
> client/, clientgui/ and lib/.


It was an example, Christian.
For what matters, I now filter on client, mgr, mac, lib, scr, winbuild,
locale, curl, openssl, zlib, linux, vbox and for completeness, server. Just
because all of those at times make up a working client.


-- Jord van der Elst.
___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Christian Beer]

On 29.03.2017 16:36, Jord van der Elst wrote:
> There were many commits, but all those commits don't necessarily make it
> into a client build. That completely depends on what's in David's build
> directory. If he just added those two commits, it's just those two commits
> that made it.

That is not how git works. It's not a matter of what was in David's
build directory it's a matter of which commit was used to checkout the
build directory (more technically: to which commit did HEAD point to
when the build was done). So what we need to know is the exact SHA1 that
was used to build the Client/Manager that was bundled into the
installer. That SHA1 can then be used to build the exact same versions
for Linux and Mac. It probably is f640f89b while it should have been
7436252a (btw: a good example for a non-atomic commit) but there is only
one person who knows that.

> e.g. I'll add all the "client" commits that were made since June 06 2016
> (which is when 7.6.33 was released, so count from that day onwards) to this
> email. They may all be commits, but they don't all have to be in 7.7.2. And
> that's why I said earlier, that I think we won't know until David says what
> he added.

If the Client/Manager was built from one of the commits above then every
commit in master is part of the history of this version. Since the 7.6
series diverged from master when the client_release/7/7.6 branch was
created there are commits that are in both branches (master and the
release branch), only in the release branch and that are only in master
because they were never cherry-picked into the release branch. That
makes it hard to say what changed between 7.6.33 and 7.7.2. Using the
release date is also not a good idea as this does not show the commits
in master that ar enot part of the release branch. You need to know the
SHA1 of this build (6f6c8b7eb). So you now need to look at the commit
history between the two SHA1.

There are a total of 3675 commits between those two SHA1 and github only
shows the 250 most recent:
https://github.com/BOINC/boinc/compare/client_release/7.6/7.6.33...7436252a
(if you see the unicorn just reload)

You can achieve the same locally via "git log --pretty=format:"%h : %s"
--graph client_release/7.6/7.6.33...7436252a" which will give you the
exact difference between those two SHA1 going back until the divergence
of the 7.6 release branch. There are supposed to be a lot of duplicates
in there (differing only by SHA1) as some contributors didn't
cherry-pick but created new commits when they added changes to master
and the release branch.

Restricting to commits that have "client" in the commit title is also
wrong as there is no commit discipline in BOINC (aka. no atomic commits)
and you can have client changes embedded in other commits (where the
message doesn't state that). You would need to at least include commit
titles with "lib" too and that would probably still miss a lot of
changes. You would need to restrict to commits that changed files in
client/, clientgui/ and lib/.

I think it's a good idea to follow Richards suggestion to treat 7.7.2 as
a private build and just forget that it exists (as we forget that there
is no version 7.7.0 and version 7.7.1). Then come up with a proper plan
to go forward with 7.7/7.8 that follows todays best practice.

Regards
Christian

___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Christian Beer]

On 29.03.2017 11:55, Richard Haselgrove wrote:
> I was thinking of things like 
>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
> (from https://setiathome.berkeley.edu/forum_index.php) 
>
> We used to be able to see exactly which SVN patches had been applied by any 
> given project, and advise accordingly. 

That was the poor man's version of a proper server version management.
It stopped working with the svn to git migration. I agree it is a nice
way to see what version projects have running. But it also opens a can
of worms with regards to security. There might be projects that don't
want to expose this kind of information because then it would be easier
to spot vulnerable pieces of code. A proper server versioning as well as
release management could bring this feature back.
> Would there be a way to keep the auto-generation of the date and author 
> fields, even though the Git SHA isn't helpful in this situation? 

The SHA1 would still be the best way to show the version but is not
useful because of the way git works. Every project obviously has a clone
of the main BOINC repository but they won't just checkout this and use
it on their production webserver. They probably have a separate branch
in this repository where they track project specific files and changes
to BOINC files. This way it is easy to see differences between BOINC and
the project and also inspect changes done to BOINC. New changes coming
in from BOINC can then be merged into a testing branch and after testing
into the production branch with a simple "git merge master". This way a
project can always fall back to the last known good configuration if
something goes bad. In this scheme the SHA1s are useless because they
are specific for this non-public repository and won't help any external
troubleshooter.

Even if some information is added the only thing an external
troubleshooter can do is tell the project to update this file because it
might contain a fix. The better way would be to point the project to a
specific commit that fixes the problem and they can check if they have
this commit in their fork of BOINC that they use. If they don't have it
they can investigate if they can cherry-pick that or merge all commits
until this one into their branch and deploy on their server.
> Projects also used to show a single SVN number on their server status pages, 
> which gave a glimpse of the state of their operational server code.

The same security concerns as above apply here too. With proper
versioning you would have a number or something here but It could only
reflect the version of the main BOINC repository that was used to create
the project specific fork. You still don't know what versions the
daemons are built from and how heavily modified they are. Our daemons
actually display (using --version) two SHA1; one of the repository where
we keep BOINC and one of the repository where we keep our project
specific daemon code. This way we exactly know what code changes are in
the daemons and which are not.

If a project does not have the resources to troubleshoot server related
things on their own and need the help of volunteers this might be a
legitimate reason to display such version information but if a project
does not want to publish that they should be able to disable this
completely.

Regards
Christian

___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Hi Oliver,
I'm taking about an intermediate level between 'cruncher' and 'developer'. I'm 
accredited as a 'Help desk expert' on the BOINC message boards, but I don't 
have the skills needed to be a full-blown developer in the versions of the 
various languages used within BOINC. Instead, I can (I hope) contribute by 
helping analyse symptoms, to make life easier for the real developers.
Two examples:
Even the best resourced projects - like Einstein! - can benefit from external 
diagnosis. A few months ago, I was pleased to be able to help Christian with a 
long-standing (multi-year, it turned out) BOINC preference propagation problem. 
Christian found the actual code at fault and committed the solution, but I like 
to think that this helped:
https://einsteinathome.org/content/invalid-global-preferences-problem?page=1#comment-150509

That example didn't depend on version control, but this next one did.
A few years ago, David added some extra (and very useful) exit status and error 
codes in 72368a6b205b521691af23ca65815b2ec4ac3008 (SVN 25601)
Unfortunately, the web code wasn't updated to reflect the new codes until 
f3c8ab83e91a430611bbb25ce714f5fd43b8c915 (SVN 25858) - over two months later, 
as is easier to deduce from the SVN than SHA references.
Not every project updated (or updates) their BOINC servers synchronously, and 
http://boinc.berkeley.edu/dev/forum_thread.php?id=7704=45186#45186 shows 
how I was able to demonstrate that - even after the project said they had 
updated their server code - a missed include file was still responsible for 
misleading task outcome information on their website. That diagnosis would not 
be possible today. 

On Wednesday, 29 March 2017, 14:55, Oliver Bock  
wrote:
 

 On 29/03/2017 13:22 , Richard Haselgrove wrote:
> I'm talking about the information visible to volunteers outside the core
> project staff.

I know, but what exactly do you mean by "public-facing page" and
"diagnosis"? Of what? The version of the web code or the daemons used by
a project?

> Small science projects don't have the resources (or the
> inclination) to follow every twist and turn.

I don't see how that's related to our discussion.

> Unless you support and
> enable volunteer contributions too, you lose a potentially valuable
> resource for community computing in general.

Again, I don't see how using SHA1s precludes any volunteer
contributions. I mean, we're talking about code contributions here, not
cycles, right? That means we're talking about developers, even if only
casual ones. They have to deal with git and GitHub anyway to provide
their contributions ans SHA1s shouldn't pose any hurdle to that target
audience.

Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

That is why I wanted to collect all not integrated commits and make a list
of good candidated to be rekeased.

Best regards,
Vitalii Koshura

2017-03-29 17:36 GMT+03:00 Jord van der Elst :

> There were many commits, but all those commits don't necessarily make it
> into a client build. That completely depends on what's in David's build
> directory. If he just added those two commits, it's just those two commits
> that made it.
>
> e.g. I'll add all the "client" commits that were made since June 06 2016
> (which is when 7.6.33 was released, so count from that day onwards) to this
> email. They may all be commits, but they don't all have to be in 7.7.2. And
> that's why I said earlier, that I think we won't know until David says what
> he added.
>
> * 63ed0f47f3 : client: change "njobs_fail" back to "njobs_error"
> * d310efc264 : client: parse njobs_error in state file (don't lose info on
> transition)
> * 10bcf5ed88 : client: send acct keys to acct manager only for projects
> attached via acct mgr.
> * fc1cf33315 : client: Mac: replace all deprecated Mac APIs as of OS 10.12
> * bde961e8bb : client: fix estimate of job RAM usage
> * c3eb84db1e : client: add report_results_immediately config on project
> and app levels
> * f7ae4c631b : client: Mac: continue replacing deprecated Mac APIs
> * 483f46a5f9 : client: Mac: replace all deprecated Mac APIs as of OS 10.9
> * ae319359aa : client: Mac: replace all deprecated Mac APIs as of OS 10.8
> * ae97e08a95 : client: Mac: continue replacing deprecated Mac APIs
> * 26d62f7f49 : Merge pull request #1786 from BOINC/normalize_cpumodel
> * 7eb7aeaa6b : Client: normalize whitespace in p_model and p_vendor entries
> * 7294138ddb : client: finish fix for AM prefs (BAM! used mixed
> http/https, needed to strip that off)
> * 938fad105d : client: finish last commit
> * 4427f3646d : client: revert misguided attempt to persist acct mgr info
> * 0e4b412d19 : client: ignore computing prefs from project if we're using
> prefs from acct mgr.
> * 8e84ff30b7 : client: Version check. Fix message about new version.
> * 494739b112 : client: Version check. Add force version check.
> * 26ff591876 : Client: Strip XML declaration from lookup_account_poll and
> get_all_projects_list RPC responses
> * a484b7dd6b : Merge pull request #1562 from BOINC/cpu_infos_aarch64
> * 59719e78d4 : Client: update hostinfo_test tool
> * d06936e51e : Client: merging hostinfo_unix code for ARM and AARCH64
> * bc4f734496 : Client: more refinements on 56d5e50
> * 492d8e46e8 : Client: fix compile error on AARCH64
> * d2f1324ea0 : Client: fix product_name parsing on AARCH64
> * 228817d3c6 : Client: use safe_strcat when length of source is unknown
> * 56d5e50f77 : Client: fix additional CPU infos from AARCH64
> * eef4d45db5 : Client: unescape special characters read from
> /etc/os-release
> * 0e3bc65fb3 : Client: get more CPU infos from AARCH64
> * 1d6157a88b : Client: reorder host.os_version for Linux
> * 56527398ac : Client: synchronize hostinfo_unix testtool with client
> * ede61a24ea : Client: improve Linux OS detection
> * 45bf51fe43 : Client: fix hostinfo test tool
> * f9f5adf38d : Client: add OS version detection to test tool
> * e378f53f67 : Client: add os detection to hostinfo test tool
> * d4b2e819ca : Client: fill product_name an aarch64 (test tool)
> * 9dbc0ea191 : Client: fix cpu detection for ARMv8
> * 5b8252e081 : Client: fix aarch64 cpu detection in test tool
> * a6675cf29e : Client: test cpu detection on aarch64 (armv8)
> * 1285474ca1 : Client: adjust hostinfo_test tool to what is used in the
> Client
> * f8e19d61f5 : client: fix compile warning
> * e92a398c0a : client: fix typo
> * 7cb58b5268 : client: include # GPUs in  XML, including acct
> mgr requests
> * 31a95ba10f : client: add option to use SOCKS5 for DNS
> * 9e70ef3ecb : client: code formatting
> | * 1be5229c18 : client: when attaching to an AM, see if account file
> exists
> * c44a2b45dc : client: tweak account manager logic
> * b949b87ac2 : client: njobs_fail, not njobs_error
> * 958c89c1e7 : client: account per-project CPU and GPU usage; report to
> account managers
> * 33baa0bca1 : client: fix compile errors and warnings
> * 5710a5e8c8 : client: report project-level REC to account managers
> * 2da0e5cdb1 : client: fix bug in benchmark CPU selection
> * fc2596143e : client: Mac: continue replacing deprecated Mac APIs
> * 3e9ead075a : Client: Make project_dont_detach_when_done RPC work
> correctly
> * 49275b0727 : client: consolidate comments in GPU code
> * ca3cb0c5c6 : Client: add some comments to GPU code
> * ca9061f70f : client: add ability to fake an OpenCL GPU Goal: improved
> support for OpenCL GPUs of random types (i.e. not Nvidia/AMD/Intel).
> * c75d81f4c4 : client: prioritize network (including GUI RPC) over async
> file ops
> * 8c44b2f165 : client: fix bug that could cause idle CPUs/GPUs.
> * a60f0bdb49 : client: win compile fix
> * 5e9f1d8ce1 : client: task properties tweak
> * 1fa9f485c0 : client: Win typo 

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Jord van der Elst]

There were many commits, but all those commits don't necessarily make it
into a client build. That completely depends on what's in David's build
directory. If he just added those two commits, it's just those two commits
that made it.

e.g. I'll add all the "client" commits that were made since June 06 2016
(which is when 7.6.33 was released, so count from that day onwards) to this
email. They may all be commits, but they don't all have to be in 7.7.2. And
that's why I said earlier, that I think we won't know until David says what
he added.

* 63ed0f47f3 : client: change "njobs_fail" back to "njobs_error"
* d310efc264 : client: parse njobs_error in state file (don't lose info on
transition)
* 10bcf5ed88 : client: send acct keys to acct manager only for projects
attached via acct mgr.
* fc1cf33315 : client: Mac: replace all deprecated Mac APIs as of OS 10.12
* bde961e8bb : client: fix estimate of job RAM usage
* c3eb84db1e : client: add report_results_immediately config on project and
app levels
* f7ae4c631b : client: Mac: continue replacing deprecated Mac APIs
* 483f46a5f9 : client: Mac: replace all deprecated Mac APIs as of OS 10.9
* ae319359aa : client: Mac: replace all deprecated Mac APIs as of OS 10.8
* ae97e08a95 : client: Mac: continue replacing deprecated Mac APIs
* 26d62f7f49 : Merge pull request #1786 from BOINC/normalize_cpumodel
* 7eb7aeaa6b : Client: normalize whitespace in p_model and p_vendor entries
* 7294138ddb : client: finish fix for AM prefs (BAM! used mixed http/https,
needed to strip that off)
* 938fad105d : client: finish last commit
* 4427f3646d : client: revert misguided attempt to persist acct mgr info
* 0e4b412d19 : client: ignore computing prefs from project if we're using
prefs from acct mgr.
* 8e84ff30b7 : client: Version check. Fix message about new version.
* 494739b112 : client: Version check. Add force version check.
* 26ff591876 : Client: Strip XML declaration from lookup_account_poll and
get_all_projects_list RPC responses
* a484b7dd6b : Merge pull request #1562 from BOINC/cpu_infos_aarch64
* 59719e78d4 : Client: update hostinfo_test tool
* d06936e51e : Client: merging hostinfo_unix code for ARM and AARCH64
* bc4f734496 : Client: more refinements on 56d5e50
* 492d8e46e8 : Client: fix compile error on AARCH64
* d2f1324ea0 : Client: fix product_name parsing on AARCH64
* 228817d3c6 : Client: use safe_strcat when length of source is unknown
* 56d5e50f77 : Client: fix additional CPU infos from AARCH64
* eef4d45db5 : Client: unescape special characters read from /etc/os-release
* 0e3bc65fb3 : Client: get more CPU infos from AARCH64
* 1d6157a88b : Client: reorder host.os_version for Linux
* 56527398ac : Client: synchronize hostinfo_unix testtool with client
* ede61a24ea : Client: improve Linux OS detection
* 45bf51fe43 : Client: fix hostinfo test tool
* f9f5adf38d : Client: add OS version detection to test tool
* e378f53f67 : Client: add os detection to hostinfo test tool
* d4b2e819ca : Client: fill product_name an aarch64 (test tool)
* 9dbc0ea191 : Client: fix cpu detection for ARMv8
* 5b8252e081 : Client: fix aarch64 cpu detection in test tool
* a6675cf29e : Client: test cpu detection on aarch64 (armv8)
* 1285474ca1 : Client: adjust hostinfo_test tool to what is used in the
Client
* f8e19d61f5 : client: fix compile warning
* e92a398c0a : client: fix typo
* 7cb58b5268 : client: include # GPUs in  XML, including acct
mgr requests
* 31a95ba10f : client: add option to use SOCKS5 for DNS
* 9e70ef3ecb : client: code formatting
| * 1be5229c18 : client: when attaching to an AM, see if account file exists
* c44a2b45dc : client: tweak account manager logic
* b949b87ac2 : client: njobs_fail, not njobs_error
* 958c89c1e7 : client: account per-project CPU and GPU usage; report to
account managers
* 33baa0bca1 : client: fix compile errors and warnings
* 5710a5e8c8 : client: report project-level REC to account managers
* 2da0e5cdb1 : client: fix bug in benchmark CPU selection
* fc2596143e : client: Mac: continue replacing deprecated Mac APIs
* 3e9ead075a : Client: Make project_dont_detach_when_done RPC work correctly
* 49275b0727 : client: consolidate comments in GPU code
* ca3cb0c5c6 : Client: add some comments to GPU code
* ca9061f70f : client: add ability to fake an OpenCL GPU Goal: improved
support for OpenCL GPUs of random types (i.e. not Nvidia/AMD/Intel).
* c75d81f4c4 : client: prioritize network (including GUI RPC) over async
file ops
* 8c44b2f165 : client: fix bug that could cause idle CPUs/GPUs.
* a60f0bdb49 : client: win compile fix
* 5e9f1d8ce1 : client: task properties tweak
* 1fa9f485c0 : client: Win typo fix
* 7056f49eed : client: fix problems w/ tempfile generation for async file
operations
* d0fd0aabbf : client: change temp file prefixes to 5 chars
* 2609d10163 : client: fix minor memory leak
* d7f4551f6f : client: fix bug where concurrent async file operations use
same temp file


-- Jord van der Elst.

On Wed, Mar 29, 2017 at 4:29 PM, Vitalii Koshura <

Re: [boinc_dev] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

@Jord, I'm afraid, you're wrong. Last release was made 5 Jun 2016. Since
that there was many commits.
Also there are many changed which were committed to master but were not
integrated into release branch.

Best regards,
Vitalii Koshura

2017-03-29 17:20 GMT+03:00 Jord van der Elst :

> I've just run git log on the BOINC repository and see something
> immediately:
>
> * | 967fa51ce3 : Add 7.7.2
> * | d310efc264 : client: parse njobs_error in state file (don't lose info
> on transition)
> * | 2c493f50c1 : Update Installshield files and vboxwrapper version
> * | 7436252a47 : change version to 7.7.2
>
> (You should see those in reverse, but I cannot do a reverse log because of
> my pretty formatting. I use this command: git log --since=06-06-2016
> --pretty=format:"%h : %s" --graph > logN-since0606201.txt)
>
> So I suspect that those are the only updates that made it into 7.7.2
>
>
>
> -- Jord van der Elst.
>
> On Wed, Mar 29, 2017 at 4:11 PM, Vitalii Koshura <
> lestat.de.lion...@gmail.com> wrote:
>
>> OK, in this case I'll just go through the list of commits and find the
>> corresponded issues which were fixed. I do not know what to do with tons
>> of
>> commits that were not included previously into the release branch. Maybe
>> I'll save them as some kind of 'ChangeLog'.
>>
>> Best regards,
>> Vitalii Koshura
>>
>> 2017-03-29 17:00 GMT+03:00 Oliver Bock :
>>
>> > On 29/03/2017 13:17 , Vitalii Koshura wrote:
>> > > but currently we have another situation:
>> > > master branch can not be a start point for new release branch.
>> >
>> > It's not a matter of whether it should or even can be. It's a matter of
>> > fact that the latest release (7.7.2) was build from master if I'm not
>> > mistaken. Thus the release branch needs to reflect that, otherwise the
>> > release and its branch would simply be inconsistent.
>> >
>> > 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Since David has said that v7.7.2 was essentially a test build to verify that he 
had all the build tools available for use, it might be best to regard that one 
as a pre-alpha private build, and re-start the 7.7/7.8 development branch cycle 
with proper version control from the outset. 

On Wednesday, 29 March 2017, 15:00, Oliver Bock  
wrote:
 

 On 29/03/2017 13:17 , Vitalii Koshura wrote:
> but currently we have another situation:
> master branch can not be a start point for new release branch.

It's not a matter of whether it should or even can be. It's a matter of
fact that the latest release (7.7.2) was build from master if I'm not
mistaken. Thus the release branch needs to reflect that, otherwise the
release and its branch would simply be inconsistent.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Jord van der Elst]

I've just run git log on the BOINC repository and see something immediately:

* | 967fa51ce3 : Add 7.7.2
* | d310efc264 : client: parse njobs_error in state file (don't lose info
on transition)
* | 2c493f50c1 : Update Installshield files and vboxwrapper version
* | 7436252a47 : change version to 7.7.2

(You should see those in reverse, but I cannot do a reverse log because of
my pretty formatting. I use this command: git log --since=06-06-2016
--pretty=format:"%h : %s" --graph > logN-since0606201.txt)

So I suspect that those are the only updates that made it into 7.7.2



-- Jord van der Elst.

On Wed, Mar 29, 2017 at 4:11 PM, Vitalii Koshura <
lestat.de.lion...@gmail.com> wrote:

> OK, in this case I'll just go through the list of commits and find the
> corresponded issues which were fixed. I do not know what to do with tons of
> commits that were not included previously into the release branch. Maybe
> I'll save them as some kind of 'ChangeLog'.
>
> Best regards,
> Vitalii Koshura
>
> 2017-03-29 17:00 GMT+03:00 Oliver Bock :
>
> > On 29/03/2017 13:17 , Vitalii Koshura wrote:
> > > but currently we have another situation:
> > > master branch can not be a start point for new release branch.
> >
> > It's not a matter of whether it should or even can be. It's a matter of
> > fact that the latest release (7.7.2) was build from master if I'm not
> > mistaken. Thus the release branch needs to reflect that, otherwise the
> > release and its branch would simply be inconsistent.
> >
> > 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 15:24 , Jord van der Elst wrote:
> For clarity, BOINC has always adopted that the uneven release numbers
> were development versions, while even were release versions.
> Major.uneven.revision == development, Major.even.revision == release.
> In the past only when the development version had matured to stable
> enough would it branch off to a release versions, while all development
> happened in master.

Thanks for the reminder Jord.

> While it would be nice to have a development version branched off to its
> own branch, with its own change log, this isn't how it was done in the
> past.

That's precisely my point. I'm talking about how it should be done to
improve the situation :-) Branches and tags don't hurt don't even cost a
thing. They just make everyone's (well, most people's) life much easier.

> I suspect that the only person who knows the change log for 7.7.2 is
> David, and that he should at least make this one.

There just two questions to answer:
1) Relative to which SHA1 do we need to compare (the start)?
2) Which commit was used to build the release (the end)?

The is just a matter of running
git log --reverse [more format-voodoo] start..end

You can always shrink the result down (even automatically) if you want
to exclude certain commits from the changelog. This way the changelog
won't guesswork and require MUCH less work.


Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

OK, in this case I'll just go through the list of commits and find the
corresponded issues which were fixed. I do not know what to do with tons of
commits that were not included previously into the release branch. Maybe
I'll save them as some kind of 'ChangeLog'.

Best regards,
Vitalii Koshura

2017-03-29 17:00 GMT+03:00 Oliver Bock :

> On 29/03/2017 13:17 , Vitalii Koshura wrote:
> > but currently we have another situation:
> > master branch can not be a start point for new release branch.
>
> It's not a matter of whether it should or even can be. It's a matter of
> fact that the latest release (7.7.2) was build from master if I'm not
> mistaken. Thus the release branch needs to reflect that, otherwise the
> release and its branch would simply be inconsistent.
>
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 13:17 , Vitalii Koshura wrote:
> but currently we have another situation:
> master branch can not be a start point for new release branch.

It's not a matter of whether it should or even can be. It's a matter of
fact that the latest release (7.7.2) was build from master if I'm not
mistaken. Thus the release branch needs to reflect that, otherwise the
release and its branch would simply be inconsistent.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 13:22 , Richard Haselgrove wrote:
> I'm talking about the information visible to volunteers outside the core
> project staff.

I know, but what exactly do you mean by "public-facing page" and
"diagnosis"? Of what? The version of the web code or the daemons used by
a project?

> Small science projects don't have the resources (or the
> inclination) to follow every twist and turn.

I don't see how that's related to our discussion.

> Unless you support and
> enable volunteer contributions too, you lose a potentially valuable
> resource for community computing in general.

Again, I don't see how using SHA1s precludes any volunteer
contributions. I mean, we're talking about code contributions here, not
cycles, right? That means we're talking about developers, even if only
casual ones. They have to deal with git and GitHub anyway to provide
their contributions ans SHA1s shouldn't pose any hurdle to that target
audience.

Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Jord van der Elst]

On Wed, Mar 29, 2017 at 12:08 PM, Oliver Bock 
wrote:

>
> Given that BOINC currently uses master to integrate changes one should
> branch off master when it's time to constitute a new release series,
> like 7.7. Such a branch can then be used to build releases which will be
> tagged individually (7.7.2). The branch will only receive bug fixes
> afterwards, cherry-picked from master.
>

For clarity, BOINC has always adopted that the uneven release numbers were
development versions, while even were release versions.
Major.uneven.revision == development, Major.even.revision == release.
In the past only when the development version had matured to stable enough
would it branch off to a release versions, while all development happened
in master.

You can see this in github when checking the branches, the only branches
available are the release branches (e.g. 6.6, 6.8, 6.10, 7.0, 7.2, 7.4, 7.6)

While it would be nice to have a development version branched off to its
own branch, with its own change log, this isn't how it was done in the
past. I am still trying to figure out how to easily get the change log for
7.7.2 out for the public, because I am hampered by non-working Git GUIs on
my Windows, so I'm now figuring out how to do this from the command line
(thanks for that idea!).

I suspect that the only person who knows the change log for 7.7.2 is David,
and that he should at least make this one.

Best,


-- Jord van der Elst.
___
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Laurence]

Some of you may be interested in this presentation on Git Best Practices.

https://indico.cern.ch/event/288437/

Developing in distributed open source projects with git is nothing new. 
I am surprised that a mature project like this one isn't following the 
best practises.  At the very least all releases including the server 
should be versioned, and bugs/features should be developed on branches.


Cheers,

Laurence


On 29/03/17 13:22, Richard Haselgrove wrote:

I'm talking about the information visible to volunteers outside the core 
project staff. Small science projects don't have the resources (or the 
inclination) to follow every twist and turn. Unless you support and enable 
volunteer contributions too, you lose a potentially valuable resource for 
community computing in general.

 On Wednesday, 29 March 2017, 12:11, Oliver Bock  
wrote:
  


  On 29/03/2017 12:44 , Richard Haselgrove wrote:

I agree that the SHAs would be more precise, but they'd be ugly to
display on a public-facing page,

Not sure why the public would need to know that at all anyway :-)


and less easy to do diagnosis

The admin should have no problem with SHA1s.


human brain can read five digits from a monotonic sequence, and get an
idea of vintage at a glance, but it can't do that with non-sequential SHAs.

True, but the above notwithstanding, you could always show the latest
tag in your local repo's history (and how many commits you lack) for
instance. Sure, you'd need proper server release for that but that's a
requirement for BOINC's open source ambitions anyway. There are many
ways to improve readability, if that's needed at all.


But we would need the latest SHA
included in the server daemon compilation, not just the user web sources.

Most daemons already have that IIRC.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

I'm talking about the information visible to volunteers outside the core 
project staff. Small science projects don't have the resources (or the 
inclination) to follow every twist and turn. Unless you support and enable 
volunteer contributions too, you lose a potentially valuable resource for 
community computing in general. 

On Wednesday, 29 March 2017, 12:11, Oliver Bock  
wrote:
 

 On 29/03/2017 12:44 , Richard Haselgrove wrote:
> I agree that the SHAs would be more precise, but they'd be ugly to
> display on a public-facing page,

Not sure why the public would need to know that at all anyway :-)

> and less easy to do diagnosis

The admin should have no problem with SHA1s.

> human brain can read five digits from a monotonic sequence, and get an
> idea of vintage at a glance, but it can't do that with non-sequential SHAs.

True, but the above notwithstanding, you could always show the latest
tag in your local repo's history (and how many commits you lack) for
instance. Sure, you'd need proper server release for that but that's a
requirement for BOINC's open source ambitions anyway. There are many
ways to improve readability, if that's needed at all.

> But we would need the latest SHA
> included in the server daemon compilation, not just the user web sources.

Most daemons already have that IIRC.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

@Oliver,
Yes, I mean 'no write access', sorry for misprint.
Also I totally agreed with you but currently we have another situation:
master branch can not be a start point for new release branch. Ok, it can
be but in this case it will require much more testing I afraid.
I think we need David here. If he will decide to create 7.7 branch based on
master branch than I'll just create a list of issues which were fixed in
this release.

Thanks

Best regards,
Vitalii Koshura

2017-03-29 14:06 GMT+03:00 Oliver Bock :

> On 29/03/2017 12:30 , Vitalii Koshura wrote:
> > I will not do any any cherry-picks because I have write access to the
> repo.
>
> You mean "no write access"?
>
> > If you will look at the current branch tree you will see that every new
> > release branch bases on previous release branch. And master branch is a
> > sandbox. It contains some commits which are too risky to be included
> > into release.
>
> Both of that needs to be changed anyway to ensure proper release
> management. Since master is used for integration is should always be as
> stable as possible (don't break master!). That usually means development
> has to happen in dedicated feature branches. This also ensures that
> independent developments don't affect each other which will make the
> whole process more efficient.
>
> > Also if you will take a look at any release banch you will
> > see that all commits were integrated there separately one by one.
>
> This doesn't mean that this approach is sensible or that it should be
> continued in the future. Again, cherry-picking like that is error-prone
> (as you said, it's hard) and cumbersome. Our goal needs to be to make
> the release process much safer/simpler and even more efficient/faster.
>
> > I think it is the best way to continue this work.
>
> I strongly disagree for the reasons above :-)
>
> > If you think this is a wrong way to do this please suggest your own.
>
> It's basically what I outlined in my previous mail and above.
>
>
> Cheers,
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 12:44 , Richard Haselgrove wrote:
> I agree that the SHAs would be more precise, but they'd be ugly to
> display on a public-facing page,

Not sure why the public would need to know that at all anyway :-)

> and less easy to do diagnosis

The admin should have no problem with SHA1s.

> human brain can read five digits from a monotonic sequence, and get an
> idea of vintage at a glance, but it can't do that with non-sequential SHAs.

True, but the above notwithstanding, you could always show the latest
tag in your local repo's history (and how many commits you lack) for
instance. Sure, you'd need proper server release for that but that's a
requirement for BOINC's open source ambitions anyway. There are many
ways to improve readability, if that's needed at all.

> But we would need the latest SHA
> included in the server daemon compilation, not just the user web sources.

Most daemons already have that IIRC.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 12:30 , Vitalii Koshura wrote:
> I will not do any any cherry-picks because I have write access to the repo.

You mean "no write access"?

> If you will look at the current branch tree you will see that every new
> release branch bases on previous release branch. And master branch is a
> sandbox. It contains some commits which are too risky to be included
> into release.

Both of that needs to be changed anyway to ensure proper release
management. Since master is used for integration is should always be as
stable as possible (don't break master!). That usually means development
has to happen in dedicated feature branches. This also ensures that
independent developments don't affect each other which will make the
whole process more efficient.

> Also if you will take a look at any release banch you will
> see that all commits were integrated there separately one by one.

This doesn't mean that this approach is sensible or that it should be
continued in the future. Again, cherry-picking like that is error-prone
(as you said, it's hard) and cumbersome. Our goal needs to be to make
the release process much safer/simpler and even more efficient/faster.

> I think it is the best way to continue this work.

I strongly disagree for the reasons above :-)

> If you think this is a wrong way to do this please suggest your own.

It's basically what I outlined in my previous mail and above.


Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

I agree that the SHAs would be more precise, but they'd be ugly to display on a 
public-facing page, and less easy to do diagnosis - the human brain can read 
five digits from a monotonic sequence, and get an idea of vintage at a glance, 
but it can't do that with non-sequential SHAs.
Perhaps it could be embedded as a comment in the page source, in the same way 
as the other php includes? But we would need the latest SHA included in the 
server daemon compilation, not just the user web sources. 

On Wednesday, 29 March 2017, 11:11, Oliver Bock  
wrote:
 

 On 29/03/2017 11:55 , Richard Haselgrove wrote:
> Would there be a way to keep the auto-generation of the date and
> author fields, even though the Git SHA isn't helpful in this
> situation?

Yes, use "git log" (see man page for tons of tailoring options).

> Projects also used to show a single SVN number on their server status
> pages, which gave a glimpse of the state of their operational server
> code.

The SHA1s do exactly that, even more precisely.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

@Oliver,
I will not do any any cherry-picks because I have write access to the repo.
If you will look at the current branch tree you will see that every new
release branch bases on previous release branch. And master branch is a
sandbox. It contains some commits which are too risky to be included into
release. Also if you will take a look at any release banch you will see
that all commits were integrated there separately one by one.
I think it is the best way to continue this work.
In any case, as I said previously, cherry-picking is the better way to
integrate needed commits only. And my job now is to create a list of
commits which should be included into release with the links to the
corresponded issues (of course, it's only my opinion).
Onlce I'll finish my job I'll sent the list of commits for discussing.
If you think this is a wrong way to do this please suggest your own. I
think David will be happy if you will suggest smth easier.

Thanks

Best regards,
Vitalii Koshura

2017-03-29 13:08 GMT+03:00 Oliver Bock :

> On 29/03/2017 10:33 , Vitalii Koshura wrote:
> > @Oliver, I want to build a list of recommended commits to be
> > integrated into release branch.
> > The list of 'fresh' commits (after
> > 6.6.33) will be very short (less than 100 commits). Also I want to
> > see older commits which were not released for some reasons (maybe
> > some of them were just missed) and give them a chance to be reviewed
> > one more time.
>
> Hm, I don't think I understand what you're trying to achieve. Let me
> start with what you wrote earlier:
>
> > 1 - create new release branch 'client_release/7/7.7' based on
> > 'client_release/7/7.6'
> > 2 - merge necessary commits using 'cherry-pick' from master branch.
>
> Why would you do that? What's the point of basing 7.7 on 7.6? Also,
> cherry-picking commits is error-prone for the purpose you outlined.
>
> Given that BOINC currently uses master to integrate changes one should
> branch off master when it's time to constitute a new release series,
> like 7.7. Such a branch can then be used to build releases which will be
> tagged individually (7.7.2). The branch will only receive bug fixes
> afterwards, cherry-picked from master.
>
> Given that there is no client_release/7/7.7 branch yet, I strongly
> recommend to use the commit David based his latest client release on
> (presumably 967fa51c). That commit should also get the
> client_release/7.7/7.7.2 tag. Based on that the 7.7 branch can then be
> used for further maintenance and bug fix releases while further
> development happens in master, until it's time for 7.8 to branched off
> master.
>
>
> Cheers,
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 11:55 , Richard Haselgrove wrote:
> Would there be a way to keep the auto-generation of the date and
> author fields, even though the Git SHA isn't helpful in this
> situation?

Yes, use "git log" (see man page for tons of tailoring options).

> Projects also used to show a single SVN number on their server status
> pages, which gave a glimpse of the state of their operational server
> code.

The SHA1s do exactly that, even more precisely.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 10:33 , Vitalii Koshura wrote:
> @Oliver, I want to build a list of recommended commits to be
> integrated into release branch.
> The list of 'fresh' commits (after
> 6.6.33) will be very short (less than 100 commits). Also I want to
> see older commits which were not released for some reasons (maybe
> some of them were just missed) and give them a chance to be reviewed
> one more time.

Hm, I don't think I understand what you're trying to achieve. Let me
start with what you wrote earlier:

> 1 - create new release branch 'client_release/7/7.7' based on
> 'client_release/7/7.6'
> 2 - merge necessary commits using 'cherry-pick' from master branch.

Why would you do that? What's the point of basing 7.7 on 7.6? Also,
cherry-picking commits is error-prone for the purpose you outlined.

Given that BOINC currently uses master to integrate changes one should
branch off master when it's time to constitute a new release series,
like 7.7. Such a branch can then be used to build releases which will be
tagged individually (7.7.2). The branch will only receive bug fixes
afterwards, cherry-picked from master.

Given that there is no client_release/7/7.7 branch yet, I strongly
recommend to use the commit David based his latest client release on
(presumably 967fa51c). That commit should also get the
client_release/7.7/7.7.2 tag. Based on that the 7.7 branch can then be
used for further maintenance and bug fix releases while further
development happens in master, until it's time for 7.8 to branched off
master.


Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

(copying my private replies to the list)


I was thinking of things like 

 
 
 
 
 
 
 
 
 
 

(from https://setiathome.berkeley.edu/forum_index.php) 

We used to be able to see exactly which SVN patches had been applied by any 
given project, and advise accordingly. 

Would there be a way to keep the auto-generation of the date and author fields, 
even though the Git SHA isn't helpful in this situation? 

Projects also used to show a single SVN number on their server status pages, 
which gave a glimpse of the state of their operational server code.

On Wednesday, 29 March 2017, 9:32, David Anderson  
wrote:



The server code was never versioned per se.
It has a change log that is not up to date:
http://boinc.berkeley.edu/trac/wiki/ServerUpdates
-- 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

@Oliver,
I want to build a list of recommended commits to be integrated into release
branch.
The list of 'fresh' commits (after 6.6.33) will be very short (less than
100 commits). Also I want to see older commits which were not released for
some reasons (maybe some of them were just missed) and give them a chance
to be reviewed one more time.

Best regards,
Vitalii Koshura

2017-03-29 11:27 GMT+03:00 Oliver Bock :

> On 29/03/2017 10:17 , Vitalii Koshura wrote:
> > Merge commits are not good candidates to be merged integrated into
> > release branch because it's hard to understand what commits were exactly
> > merged.
>
> Ah, we seem to have a misunderstanding here. I thought you were
> gathering a list commits such that a changelog for the latest client
> release could be compiled.
>
> The above sounds like you want to create a release branch after David
> released the latest client from some (still unknown?) commit. If this is
> the case, do you really want to built that branch manually by
> cherry-picking commits?
>
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[David Anderson]

The server code was never versioned per se.
It has a change log that is not up to date:
http://boinc.berkeley.edu/trac/wiki/ServerUpdates
-- David

On 3/29/2017 1:16 AM, Richard Haselgrove wrote:

And these particular change logs -


http://boinc.berkeley.edu/wiki/Release_Notes_for_BOINC_7.6

https://boinc.berkeley.edu/dev/forum_thread.php?id=10204


are for the Client and GUI only - the server code isn't versioned any longer. 
Sadly.


On Wednesday, 29 March 2017, 9:09, David Anderson  
wrote:


The change logs are for volunteers,
so that they can see a summary of functional changes and decide whether to 
upgrade.
People who want to see commit notes can read them easily enough.
-- David

On 3/29/2017 1:04 AM, Oliver Bock wrote:
> On 29/03/2017 9:40 , Vitalii Koshura wrote:
>>  From my POV the the most hard part of this is to select important
>> commits only.
> As long as you ignore merge commits, which is easy given their common
> commit message prefix, EVERY commit is important. Changelogs are for
> *various* user groups and thus should be complete (you won't know what's
> "important"!). Sure, this all depends on having proper commits (atomic,
> message prefixes) in the first place, but that's a different problem.
>
> tl;dr: given our scarce resources changelogs should be created
> automatically, as part of a proper release process. Proper commit
> discipline is needed to facilitate that but it's easy to come by.
> Disregarding commit discipline "in favor of" manual changelog harvesting
> would be ridiculous.
>
> Cheers,
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 10:17 , Vitalii Koshura wrote:
> Merge commits are not good candidates to be merged integrated into
> release branch because it's hard to understand what commits were exactly
> merged.

Ah, we seem to have a misunderstanding here. I thought you were
gathering a list commits such that a changelog for the latest client
release could be compiled.

The above sounds like you want to create a release branch after David
released the latest client from some (still unknown?) commit. If this is
the case, do you really want to built that branch manually by
cherry-picking commits?

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 10:09 , David Anderson wrote:
> The change logs are for volunteers,
> so that they can see a summary of functional changes and decide whether
> to upgrade.

That's one important aspect, yes. However, functional changes can also
be "internal" so a changelog is also very valuable for the downstream
projects or even client developers. You might consider marking
volunteer-facing commits such that an automated changelog could
highlight them though.

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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

And these particular change logs -

http://boinc.berkeley.edu/wiki/Release_Notes_for_BOINC_7.6

https://boinc.berkeley.edu/dev/forum_thread.php?id=10204


are for the Client and GUI only - the server code isn't versioned any longer. 
Sadly. 

On Wednesday, 29 March 2017, 9:09, David Anderson  
wrote:
 

 The change logs are for volunteers,
so that they can see a summary of functional changes and decide whether to 
upgrade.
People who want to see commit notes can read them easily enough.
-- David

On 3/29/2017 1:04 AM, Oliver Bock wrote:
> On 29/03/2017 9:40 , Vitalii Koshura wrote:
>>  From my POV the the most hard part of this is to select important
>> commits only.
> As long as you ignore merge commits, which is easy given their common
> commit message prefix, EVERY commit is important. Changelogs are for
> *various* user groups and thus should be complete (you won't know what's
> "important"!). Sure, this all depends on having proper commits (atomic,
> message prefixes) in the first place, but that's a different problem.
>
> tl;dr: given our scarce resources changelogs should be created
> automatically, as part of a proper release process. Proper commit
> discipline is needed to facilitate that but it's easy to come by.
> Disregarding commit discipline "in favor of" manual changelog harvesting
> would be ridiculous.
>
> Cheers,
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

Hello Oliver,

Merge commits are not good candidates to be merged integrated into release
branch because it's hard to understand what commits were exactly merged.

Thanks

Best regards,
Vitalii Koshura

2017-03-29 11:04 GMT+03:00 Oliver Bock :

> On 29/03/2017 9:40 , Vitalii Koshura wrote:
> > From my POV the the most hard part of this is to select important
> > commits only.
>
> As long as you ignore merge commits, which is easy given their common
> commit message prefix, EVERY commit is important. Changelogs are for
> *various* user groups and thus should be complete (you won't know what's
> "important"!). Sure, this all depends on having proper commits (atomic,
> message prefixes) in the first place, but that's a different problem.
>
> tl;dr: given our scarce resources changelogs should be created
> automatically, as part of a proper release process. Proper commit
> discipline is needed to facilitate that but it's easy to come by.
> Disregarding commit discipline "in favor of" manual changelog harvesting
> would be ridiculous.
>
> Cheers,
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[David Anderson]

The change logs are for volunteers,
so that they can see a summary of functional changes and decide whether to 
upgrade.
People who want to see commit notes can read them easily enough.
-- David

On 3/29/2017 1:04 AM, Oliver Bock wrote:

On 29/03/2017 9:40 , Vitalii Koshura wrote:

 From my POV the the most hard part of this is to select important
commits only.

As long as you ignore merge commits, which is easy given their common
commit message prefix, EVERY commit is important. Changelogs are for
*various* user groups and thus should be complete (you won't know what's
"important"!). Sure, this all depends on having proper commits (atomic,
message prefixes) in the first place, but that's a different problem.

tl;dr: given our scarce resources changelogs should be created
automatically, as part of a proper release process. Proper commit
discipline is needed to facilitate that but it's easy to come by.
Disregarding commit discipline "in favor of" manual changelog harvesting
would be ridiculous.

Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

Hello Richard,

Thank you for your help.
I want to be sure that I'll not miss some important commits so I'll check
them all.

Best regards,
Vitalii Koshura

2017-03-29 10:56 GMT+03:00 Richard Haselgrove 
:

> Using TortoiseGit on a clone, I found that viewing the log from the client
> and clientgui folders only - effectively filtering to select commits which
> touched files in those folders only - generated a shortlist which might be
> helpful.
>
>
> On Wednesday, 29 March 2017, 8:40, Vitalii Koshura <
> lestat.de.lion...@gmail.com> wrote:
>
>
> Hello Oliver,
>
> Thank you for advice.
> From my POV the the most hard part of this is to select important commits
> only.
>
> Best regards,
> Vitalii Koshura
>
> 2017-03-29 9:36 GMT+03:00 Oliver Bock :
>
> > Hi Vitalii,
> >
> > On 28/03/2017 9:34 , Vitalii Koshura wrote:
> > > I can do the hard job and prepare the list of commits for 7.7 release
> and
> > > also prepare the list of fixes with issue numbers.
> >
> > That doesn't need to be hard. Just use git (log) and generate the
> > changelog. All you need to know to do that are the start and end points
> > (SHA1s) of the range of commits - but you have to know those as well to
> > it manually.
> >
> > 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

On 29/03/2017 9:40 , Vitalii Koshura wrote:
> From my POV the the most hard part of this is to select important
> commits only.

As long as you ignore merge commits, which is easy given their common
commit message prefix, EVERY commit is important. Changelogs are for
*various* user groups and thus should be complete (you won't know what's
"important"!). Sure, this all depends on having proper commits (atomic,
message prefixes) in the first place, but that's a different problem.

tl;dr: given our scarce resources changelogs should be created
automatically, as part of a proper release process. Proper commit
discipline is needed to facilitate that but it's easy to come by.
Disregarding commit discipline "in favor of" manual changelog harvesting
would be ridiculous.

Cheers,
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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Richard Haselgrove]

Using TortoiseGit on a clone, I found that viewing the log from the client and 
clientgui folders only - effectively filtering to select commits which touched 
files in those folders only - generated a shortlist which might be helpful. 

On Wednesday, 29 March 2017, 8:40, Vitalii Koshura 
 wrote:
 

 Hello Oliver,

Thank you for advice.
>From my POV the the most hard part of this is to select important commits
only.

Best regards,
Vitalii Koshura

2017-03-29 9:36 GMT+03:00 Oliver Bock :

> Hi Vitalii,
>
> On 28/03/2017 9:34 , Vitalii Koshura wrote:
> > I can do the hard job and prepare the list of commits for 7.7 release and
> > also prepare the list of fixes with issue numbers.
>
> That doesn't need to be hard. Just use git (log) and generate the
> changelog. All you need to know to do that are the start and end points
> (SHA1s) of the range of commits - but you have to know those as well to
> it manually.
>
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Vitalii Koshura]

Hello Oliver,

Thank you for advice.
>From my POV the the most hard part of this is to select important commits
only.

Best regards,
Vitalii Koshura

2017-03-29 9:36 GMT+03:00 Oliver Bock :

> Hi Vitalii,
>
> On 28/03/2017 9:34 , Vitalii Koshura wrote:
> > I can do the hard job and prepare the list of commits for 7.7 release and
> > also prepare the list of fixes with issue numbers.
>
> That doesn't need to be hard. Just use git (log) and generate the
> changelog. All you need to know to do that are the start and end points
> (SHA1s) of the range of commits - but you have to know those as well to
> it manually.
>
> 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] Fwd: Re: [boinc_alpha] R: BOINC 7.7.2 released for Win

[Oliver Bock]

Hi Vitalii,

On 28/03/2017 9:34 , Vitalii Koshura wrote:
> I can do the hard job and prepare the list of commits for 7.7 release and
> also prepare the list of fixes with issue numbers.

That doesn't need to be hard. Just use git (log) and generate the
changelog. All you need to know to do that are the start and end points
(SHA1s) of the range of commits - but you have to know those as well to
it manually.

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.