On 06.01.18 04:40, Vitalii Koshura wrote:
> In this case I'll dig a little bit deeper and send you more details.
If it doesn't have to be a fancy (yuk) node.js/electron base you should
consider Qt.
JM2C,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.b
On 06.11.17 11:14 , Oliver Bock wrote:
> How or when are updated PO templates from locale/templates propagated to
> Transifex? IIRC there was some automated bridge that was supposed to do
> this periodically.
Anyone? The resource is still not updated at Transifex..
Hi guys,
How or when are updated PO templates from locale/templates propagated to
Transifex? IIRC there was some automated bridge that was supposed to do
this periodically.
Thanks,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lis
On 22/08/17 3:07 , David Anderson wrote:
> What GPU info does the CAL function provide that OpenCL doesn't?
This is the most important question IMHO. The OpenCL API doesn't cover
certain device details (like free device memory) that might be relevant
for task scheduling and are currently still onl
Hi Richard,
On 21/08/17 12:02 , Richard Haselgrove wrote:
> Could somebody explain - or possibly review - "post trimming" on a
> drupal message board, please? I was wondering why my final sentence
> was removed from the attached screenshot.
Please note that this is a trimmed preview, not a trimme
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/MI
On 08/08/17 16:16 , Laurence wrote:
>> http://nvie.com/posts/a-successful-git-branching-model
> On the positive side it looks like we are not too far away from this model:
From the model we'd like to see used, yes.
smime.p7s
Description: S/MIME Cryptographic Signature
__
On 08/08/17 8:23 , David Anderson wrote:
> https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
Thanks for the link. That document shows why we are in disagreement.
There are statements in there which are invalid generalized conclusions
based on limited personal experience and knowledge. Something
On 08/08/17 11:55 , Steffen Möller wrote:
> More discussions in this thread do more harm than good in my experience,
Well, at least a few people pointed out that they indeed learned a lot
from these discussions. Apart from that I think the positions of
everyone who voiced an opinion became a lot c
On 08/08/17 10:46 , Laurence wrote:
> However, there is an assumption here that the build and testing
> is all done by the project.
Up to a certain point I think that's true (see below).
> For the Linux client on Fedora (and Debian),
> only a reference to the code in git is required. What is vers
On 08/08/17 10:29 , Christian Beer wrote:
> - a bug is found and fixed in "base" (via a pull request) maybe totally
> independent from testing the release
> - the developer who fixed the bug tells the release manager to include
> this fix into the release branch, this can not happen via a merge fro
On 08/08/17 10:41 , Jason Groothuis wrote:
> Careful. If I need to get Hans Dokter in here, well...
Some sayings just escape me...
smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://li
On 08/08/17 10:26 , Richard Haselgrove wrote:
> * Failing to ensure that a bugfix is carried forward into the next cycle
> * Allowing untested code to creep into a release
Won't happen if you follow the process I just described in my reply to
your previous mail :-)
Other than that, increase conti
On 08/08/17 9:49 , Richard Haselgrove wrote:
> Clearly they need to be in the codebase which is being prepped for
> release: but they also need to be in the core development line which
> will form the basis for the next round of development. And we don't want
> to allow new features to creep into t
On 08/08/17 10:12 , Laurence wrote:
> My comment was referring to
> maintaining the release so creating the major.minor branch right after
> publishing.
Does that mean you want to publish a release based on (build from)
master and only then create a release branch? That would be very unusual
and I
Hi Laurence,
On 07/08/17 23:11 , Laurence Field wrote:
> On 07/08/17 09:55, Oliver Bock wrote:
>>
>> As Laurence pointed out: release branches are to stabilize
>> and fix releases.
>>
> This is not what I intended to communicate. When the master (which
> s
On 07.08.2017 16:21, Steffen Möller wrote:
> So, please find a way to stop this so very outdated discussion.
This discussion is meant to help reaching a consensus on how to do
things in the future - the very things you asked for. Only when one
established the how one can establish the who.
> Heck
On 06/08/17 22:40 , David Anderson wrote:
> Testing a feature in isolation is not the same as testing the system.
True.
> No one is advocating committing untested or buggy code into master.
Yet it happens most of the time, mostly because *development* happens in
master. And even if one sees a se
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
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 y
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
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 "g
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
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 ident
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 n
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 un
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 po
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
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.
On 31/07/17 10:33 , Jason Groothuis wrote:
> We know Oliver, We know.
To be fair, I was only referencing your comment on "modernised
development methodology", not BOINC's practicality. Regarding the
former, every single community voice I heard so far argued in the same
way and agreed with one anot
On 31/07/17 10:19 , Jason Groothuis wrote:
> If that's not clear enough (as usual with my particular mode of
> speech), I'm completely with Christian on this, for forking BOINC to
> something practical, and am in full favour of a modernised
> development methodology.
Fortunately, the (visible) com
Hi David,
On 22/07/17 10:13 , David Anderson wrote:
> On 7/21/2017 1:26 AM, David Wallom wrote:
>> the responsibility for functions to different community groups. As
>> such it will be essential that we move to a multi branch development
>> methodology in some form of public repository. I use this
On 22/07/17 10:19 , Steffen Möller wrote:
>> On 7/21/2017 1:26 AM, David Wallom wrote:
>>> the responsibility for functions to different community groups. As
>>> such it will be essential that we move to a multi branch development
>>> methodology in some form of public repository. I use this in a l
On 21/07/17 10:26 , David Wallom wrote:
> Another thing I would like to introduce (at risk of a large back lash
> ;) is the type of open source license currently used for BOINC.
Please let's use a different thread and/or the workshop to discuss this.
Thanks :-)
smime.p7s
Description: S/MIME Cr
Hi David,
On 21/07/17 0:50 , David Anderson wrote:
> This discussion comes down to two contrasting models for software
> development:
Sorry, no, that's not the point.
> 1) The "waterfall model":
> 2) The "agile model":
I know both models very well, professionally and scientifically.
> Requirem
On 20/07/17 11:11 , Oliver Bock wrote:
> If you don't adapt and progress it
> can only get worse, in particular from the point of view of newly
> interested scientists and contributors.
Just in case this came across in an offending way: the "you" wasn't
meant person
On 20/07/17 12:06 , David Anderson wrote:
> As far as I can tell, none of the issues you mention have anything to do
> with whether
> we call master a "development branch" or an "integration branch".
I know. That's why I keep trying to address that.
> You seem to think that people who don't buy i
On 20/07/17 10:09 , David Anderson wrote:
>> Sorry, but this isn't a sustainable model.
> Well, it's sustained us this far.
Well, in that case we have a different understanding of "sustainable".
Yes, BOINC survived, barely, but did it strive? Is it easy (let alone
fun) to use for downstream projec
Hi David,
On 20/07/17 9:11 , David Anderson wrote:
> Master is for new development.
Sorry, but this isn't a sustainable model. Since only the client uses
release branches *all* other components (e.g. the server!) depend on
master being "usable". Therefore master should always be as stable as
poss
On 19.07.17 12:24, Oliver Bock wrote:
> Other than that I'm fully in line with your proposal as it reflects what
> I've already proposed here:
>
> https://github.com/BOINC/boinc/issues/1874
Given the existence of that issue all further (related) discussion would
ideally b
On 19/07/17 11:57 , Christian Beer wrote:
> - if there is consensus that the feature is useful to BOINC in general
> and known to be stable enough, the developer creates a pull request to
> merge the feature into the master branch
> - if the feature involves client changes, a new client version can
On 08.05.17 16:26 , Gianfranco Costamagna wrote:
> Is anybody working on it?
If so, please take a look at this issue:
https://github.com/BOINC/boinc/issues/1874
Cheers
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/
Hi James,
On 30.04.17 6:50 , James Whitley wrote:
> Android version 5.0
Which version of Android is this exactly? Also, is this plain Android
(AOSP) or some vendor "enhanced" flavor of it?
Please note that if you have a GitHub account you may directly add your
answers to this issue:
https://git
Hi David A.
On 08.04.17 2:13 , David Anderson wrote:
> I made some revisions to David Kim's code and put it in a branch:
> https://github.com/BOINC/boinc/tree/android_api_dpa
Can we please use the PR David K. thankfully created for this purpose?
https://github.com/BOINC/boinc/pull/1858
> The ma
On 07.04.17 1:24 , David E Kim wrote:
> How can I push my changes? I have them ready to push but don’t have
> permission.
You don't need any permission. The usual GitHub workflow looks like this:
- Create an account on GitHub and upload a ssh public key
- Fork BOINC on GitHub (button in upper-ri
On 06.04.17 17:33 , David Kim wrote:
> but I can definitely push our
> changes to have them reviewed, updated, and tested.
That was the idea :-)
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_d
On 06.04.17 9:22 , Oliver Bock wrote:
>> and perhaps
>> try to find a solution?
>
> This remains to be seen :-)
That said, please open an issue on GitHub to facilitate tracking this
down (incl. increasing the potential of finding debugg
On 06.04.17 9:38 , David Kim wrote:
> Ok, I just posted an issue on GitHub.
Thanks.
> I also gave David Anderson our boinc_api.cpp mods.
For future contributions/fixes it would be great if you'd just push your
changes to GitHub and open a PR. This way your patches don't leave the
toolchain, attr
On 06.04.17 9:25 , Oliver Bock wrote:
> On 06.04.17 8:11 , Eric Driver wrote:
>> As a side note, do you get enough android users to justify the extra
>> work of maintaining the android app?
>
> Luckily BOINC is a community project nowadays so "extra work" is a
On 06.04.17 8:11 , Eric Driver wrote:
> As a side note, do you get enough android users to justify the extra
> work of maintaining the android app?
Luckily BOINC is a community project nowadays so "extra work" is a term
that doesn't really fit anymore, as long as there's a community willing
to sup
On 06.04.17 2:46 , Charlie Fenton wrote:
> IS there
> anyone on this list who could test this under OS 10.12.4
I can reproduce it.
> and perhaps
> try to find a solution?
This remains to be seen :-)
Best,
Oliver
___
boinc_dev mailing list
boinc_dev@s
Hi David,
On 05.04.17 20:39 , David E Kim wrote:
> I’m not sure if this is the right list to use but thought I’d mention
> it here.
If you don't mind, please open an issue for this on GitHub to facilitate
tracking down this problem.
Thanks,
Oliver
___
On 29/03/2017 17:59 , Christian Beer wrote:
> 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.
That's precisely my point. There's no point in thinking/guessing about
what might be part of a given release. That's app
Hi Richard,
On 29/03/2017 17:07 , Richard Haselgrove wrote:
> Not every project updated (or updates) their BOINC servers
> synchronously,
> and http://boinc.berkeley.edu/dev/forum_thread.php?id=7704&postid=45186#45186
> shows
> how I was able to demonstrate that - *even after the project said the
On 29/03/2017 17:11 , Christian Beer wrote:
> 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. T
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 versi
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
mis
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
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.
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
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
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 som
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
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 th
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
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
On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.
Please, please, please. It's been about three years since we migrated to
git. BOINC moved to GitHub just recently and tries to adopt a community
governance model. It should really be possible by now that devs start
using feature branches
On 26/11/15 15:20 , Christian Beer wrote:
> We are currently looking into how to get a cross signed certificate that
> is present in the old ca-bundle and still valid.
Done!
FTR, Thawte users can append the following two CA roots to their chain
file (in this order):
1) Alternative "thawte Primar
Dear BOINC devs/committers,
When you revert a commit, please add a word or two describing the reasoning.
Thanks,
Oliver
PS: Kudos for using git revert at all!
Forwarded Message
Subject: [boinc_cvs] [BOINC/boinc] 493c9d: Revert "lib: Prevent the
xml_unescape function fro...
D
Hi all,
On 17/10/15 3:07 , AgentB wrote:
> The resultsRPC could be used in a number of ways in the future
>
> Future versions of boinc or the boincmgr could use it to
> + put an alert notice if a new error detected recently
> + log the event, like the job_.txt files
> + put a last week scorecard
On 14/10/15 0:49 , David Anderson wrote:
> FYI. I'm not sure how to fix these, or if they matter.
See below...
> *** CID 117636: Insecure data handling (TAINTED_SCALAR)
> /sched/size_regulator.cpp: 85 in main()
> 79 hi = atoi(argv[++i]);
> 80 } else if (!strcmp(argv
On 17/09/15 9:34 , fox.ky...@jifox.cz wrote:
> Also the same question about wiki pages. Any changes there? I cannot login
> with right login credentials
Hm, works just fine for me (as long as we talk about trac@berkeley)...
O.
smime.p7s
Description: S/MIME Cryptographic Signature
On 17/09/15 9:31 , fox.ky...@jifox.cz wrote:
> Was there any change to the link for source code? I got just 'connection
> refused' with using:
>
> git clone git://boinc.berkeley.edu/boinc-v2.git boinc-src
Yes, it moved here: https://github.com/BOINC/boinc
Oliver
smime.p7s
Description: S/MIM
Hi David,
On 06/08/14 10:02 , Bernd Machenschalk wrote:
> Oliver has already mentioned that we use this approach in the
> BOINC-Drupal project and has pointed out the XML specification that was
> developed there. I think it would save time and effort for all of us to
> use this as a basis.
That's
Hi Lukasz,
On 19/06/14 10:02 , lswierczewski . wrote:
> What file contains the declarations of structures DB_HOST
db/boinc_db.h
> and RESULT?
> db/boinc_db_types.h
Best,
Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev
On 15/04/14 17:37 , Rom Walton wrote:
> In order to exploit the client wouldn't a project server using SSL have
> to be compromised?
Yes, or use a man-in-the-middle-attack...
Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
___
boinc_dev
On 15/04/14 16:38 , Rom Walton wrote:
> Since the client doesn't use SSL in a server-role it doesn't need to be
> backported to older branches.
Not sure I understand you correctly but Heartbleed is a bi-directional
issue. So yes, client libs need to be updated to protect the client - as
you alread
On 15/04/14 13:56 , TarotApprentice wrote:
> Apart from all the hype I presume BOINC will need to come bundled
> with a patched OpenSSL and the projects need to update to a later
> version incorporating a patched OpenSSL. Any advice from the BOINC
> developers?
Charlie already updated OpenSSL bund
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/03/14 19:30, Toralf Förster wrote:
> Just for completeness: from this :
> http://git-scm.com/book/en/Git-Basics-Tagging it seems to be that a
> signed tag is always an annotated tag too, right ?
Yes. The signature just becomes part of the annota
Hi Rom,
On 14/03/14 19:10, Rom Walton wrote:
> The basic problem at the moment is TortiseGit is 64-bit while Gpg4win
> is 32-bit. TortiseGit cannot see/use the 32-bit gpg-agent to extract
> the signing key I created.
As I said earlier, this is not about tag signing. You can still use
annotated t
On 14/03/14 15:00 , Toralf Förster wrote:
> Is there a reason in this project to not use annotated tags here ?
Not to my knowledge. Maybe ease of use...?
Release tags in particular could (or even should) be annotated tags
because it wouldn't make much sense to update or delete them afterwards
- t
On 04/03/14 16:54 , Toralf Förster wrote:
> Would the usage of signed git tags improves the readability of "git
> describe" ?
No, because this is not about signed vs. unsigned tags but about
annotated (signed or unsigned) vs. lightweight tags.
If you want to include lightweight tags just add --ta
On 17/02/14 15:39 , William wrote:
> This is exactly why linear should be the default. Dynamic should
> be available only to those projects that care enough to set it up
> properly. Linear should apply to the lazy ones unless and until
> they take the time to deliberately opt in.
And this is whe
e intended new linear switch would cause a fully dynamic
calculation.
> If there isn't, then make the linear version be opt in, not the old one.
Yep, that's what I'd like to see (see earlier mails).
Oliver
> -Original Message-
> From: Oliver Bock [mailto:oliver.b
Hi John,
On 14/02/14 3:48 , McLeod, John wrote:
> Having the current method be opt in is no better than having a new method be
> opt in – for exactly the same reasons.
I concur with William: if projects miss to opt for using the
linear/dynamic flag they'll only hurt themselves. This is a
self-co
On 14/02/14 8:30 , David Anderson wrote:
> I'd prefer to figure out why the static estimates are off.
> If an app's jobs are of a size proportional to wu.rsc_fpops_est,
> the static estimates should be almost exact, even for a host's first jobs.
The static estimates are often very rough ones becau
On 13/02/14 11:00 , Heinz-Bernd Eggenstein wrote:
> If an estimate is just "it will take 100 hrs, 10 min, 5 sec" , updated
> every second, the user reaction will (understandably) be different
> compared to something like (say)
> "100 hrs (+/- 80 hrs)".
In addition to HBE's approach above, I r
Hi Toralf,
>IMHO the current "Forced update of the master branch" topic of the
>mailing list is a good reminder to rethink about the current "git
>commit" / "git push" / "git tag" policy.
The use of the master branch for development as well as major/minor release
branches for maintenance isn't t
On 06/12/13 16:39 , Oliver Bock wrote:
> - git reflog expire --expire=all --expire-unreachable=all --all
> - git gc --aggressive --prune=all
Let me add that these two steps are optional and just meant to reclaim
wasted diskspace (120 MB). This is going to happen automatically after
30-9
Hi everyone,
We removed the binaries that got accidentally added to the master
branch. This required to partially rewrite the history, affecting all
commits after 229c1c5.
What does this mean for you?
First of all, if you haven't yet pulled beyond 229c1c5 you can stop
reading and pull whenever y
On 25/11/13 15:39 , Joachim Fritzsch wrote:
> What do you think?
Nice and useful!
One minor comment: you want to separate the icon and the label of the
top menu bar buttons more clearly. See "Preferences" for instance:
https://www.dropbox.com/sh/i1ebp0xffoujx3m/H_jKaIQwNa#lh:null-6-nexus7-potrai
On 06/11/13 20:32 , Jord van der Elst wrote:
> On Wed, Nov 6, 2013 at 8:17 PM, Oliver Bock wrote:
>> In case of the hardware beta I'd expect Valve to be very selective
>> because of the natural shortage of prototype machines. I'd expect that
>> they focus on gam
Hi Carl,
On 06/11/13 17:07, Carl Christensen wrote:
> I signed up as I figured if there's a USB port it could be cheap &
> easy to host a USB accelerometer for QCN; but their vetting process
> to become a member is a bit ridiculous. I did the Raspberry Pi &
> GuruPlug computers and they were much
Hi,
Has anyone yet considered getting BOINC to run on Valve's upcoming
hardware and operating system? Is anyone participating in the beta program?
http://store.steampowered.com/livingroom/SteamMachines
http://store.steampowered.com/livingroom/SteamOS
Both look really interesting, considering the
On 10/1/13 19:55 , Joachim Fritzsch wrote:
> I have uploaded screen shots to my public dropbox folder:
> https://www.dropbox.com/sh/i1ebp0xffoujx3m/H_jKaIQwNa
>
> It is quite hard to capture, since most transfers are over within
> seconds on a decent wifi connection.
>
> On one of the screen shot
On 5/29/13 11:51 , "Steffen Möller" wrote:
>> Yeah - I was just grumbling about a commit with the only message
>>
>> "Include instead of various places"
>>
>> nothing else - and of course gitk shows for a dozen of files such a
>> change. Every ?!&%%$$ user can see the diff using gitk - so im
On 4/23/13 15:42 , Gianfranco Costamagna wrote:
> Hi David and Oliver, this should be the final version.
Great! Looks good (the patch format, haven't checked the content)!
Thanks,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://li
On 4/23/13 15:22 , Oliver Bock wrote:
> If you provide verbose/multi-line commit messages, please use a
> subject/body format. That means:
>
> 1) use a single brief line as "subject"
> 2) followed by an empty line
> 3) then the bulk (or "body") of your
On 4/23/13 15:13 , Gianfranco Costamagna wrote:
> Should be better now :)
One final minor suggestion :-)
If you provide verbose/multi-line commit messages, please use a
subject/body format. That means:
1) use a single brief line as "subject"
2) followed by an empty line
3) then the bulk (or "bod
On 4/23/13 15:06 , Gianfranco Costamagna wrote:
> This is the second part, from Guo Yixuan, I changed in the patch the
> author line, I hope it's enough for giving credits to him!
FWIW: you can commit using separate author information by using the
following git commit option: --author="First Last
1 - 100 of 242 matches
Mail list logo
