On 2017-08-08 11:55, Steffen Möller wrote:
People on this thread take one of two positions:
a) have it the way we always had it in BOINC, mostly in ignorance of
what git could do for BOINC
b) have it the same way that git is used in any other larger Open
Source project
git by itself is jus
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
__
)
--
From: boinc_dev on behalf of Laurence
Sent: Tuesday, 8 August 2017 23:46
To: Oliver Bock; Richard Haselgrove; Laurence Field
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
On 08/08/17 10:36
On 08/08/17 10:36, Oliver Bock wrote:
For more on this I suggest you have a look at GitFlow to get an even
more complete picture:
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:
https://github.com/BOINC/boinc/
On 08.08.17 14:47, Oliver Bock wrote:
https://boinc.berkeley.edu/trac/wiki/DevMethodologies as well, at least
in two key sentences or the apparent conclusions derived from them:
- "Once we let go of the idea that master should be stable (which is
impossible for reasons given here, there is no r
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
"any other larger Open Source project"
*cough cough* Unreal engine...
___
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 you
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 07.08.17 17:51, Oliver Bock wrote:
> 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
> establ
du
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
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).
&
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
Hi Oliver,
On 08/08/17 10:22, Oliver Bock wrote:
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 r
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
)
--
From: Oliver Bock
Sent: Tuesday, 8 August 2017 18:09
To: Richard Haselgrove; Laurence; Jason Groothuis; Laurence Field
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
On 08/08/17 10
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
Sc(compSci)
--
From: Richard Haselgrove
Sent: Tuesday, 8 August 2017 17:56
To: Laurence; Jason Groothuis; Oliver Bock; Laurence Field
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
My concern was to acknowledge that h
My concern was to acknowledge that human error exists: someone, somewhere, is
bound to make a mistake. How do we maximise the chances of noticing any
mistake, and correcting it quickly?
In the context of release management, I see two possible classes of mistake:
* Failing to ensure that a bugfi
There are well proven methods to achieve this. Assuming that there is a
stable branch where all development is based on (I'll call this the
"base" branch herein) and where the "release" branch is based on, a
possible approach would be:
- the release branch is created and under testing, assume we h
: Laurence
Sent: Tuesday, 8 August 2017 17:44
To: Jason Groothuis; Oliver Bock; Laurence Field; Richard Haselgrove
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
On 08/08/17 10:03, Jason Groothuis wrote:
The old way is
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
On 08/08/17 10:03, Jason Groothuis wrote:
The old way is about control. The new way is about freedom.
Do the developers work directly for the project or are they autonomous
but wish to collaborate?
___
boinc_dev mailing list
boinc_dev@ssl.berkele
Hi Oliver,
There are two different scenarios, validating the code before the
release and maintaining the release. My comment was referring to
maintaining the release so creating the major.minor branch right after
publishing.
Cheers,
Laurence
On 08/08/17 09:36, Oliver Bock wrote:
Hi Laure
: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
Yep. Organic Vs control
--
Jason Richard Groothuis
bSc(compSci
)
--
From: boinc_dev on behalf of Richard
Haselgrove
Sent: Tuesday, 8 August 2017 17:19
To: Oliver Bock; Laurence Field
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
The major problem here (in my head at least) is
The major problem here (in my head at least) is how to treat bugfixes during
the pre-release / test / full release interval.
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 ro
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
> should be stable) has the required features
On 2017-08-08 08:23, David Anderson wrote:
Please read
https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
Yes, I did a number of times.
What exactly are you referring to?
- I am referring to development in BOINC in general, not restricted to
the server software.
- The fact that you don't
Please read
https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
-- David
On 8/7/2017 10:28 PM, Bernd Machenschalk wrote:
On 07.08.17 21:40, David Anderson wrote:
I've proposed creating server release branches,
similar to the exiting client release branches.
Hopefully this will satisfy everyone
__
From: boinc_dev on behalf of Bernd
Machenschalk
Sent: Tuesday, 8 August 2017 14:58
To: David Anderson; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Software development and branches, was Re:
[boinc_projects] keywords
On 07.08.17 21:40, David Anderson wrote:
> I've proposed crea
On 07.08.17 21:40, David Anderson wrote:
I've proposed creating server release branches,
similar to the exiting client release branches.
Hopefully this will satisfy everyone's needs.
What I (and others) need is a "stable" branch (whatever named) I can
- branch off my own development to work wit
On 8/7/2017 5:20 PM, Steffen Möller wrote:
No. It won't it is very much off the problem. Offer
separate repositories ( as in github.com/BOINC/client
and github.com/BOINC/server, not branches, and you
make people happier. Of course the two repositories
have zero code redundancy.
Perhaps you hav
Hello,
On 07.08.17 21:40, David Anderson wrote:
> Steffen:
> I agree - git is here to serve us, not vice versa :-)
;) I just removed a story on why people introduce
software like SAP in a company that has not seen
proper controlling before. Too much text.
> I've proposed creating server release b
Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
-- David
On 8/4/2017 3:38 PM, Laurence Field wrote:
Hi David,
On 04/08/17 23:17, David Anderson wrote:
It's simple:
1) fork master, e.g. to client_release_xxx. It's not stable at this point.
2) test client_release_xxx (e.g. us
HI Oliver,
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
should be stable) has the required features and been tested, a release
is made and a branch versi
Steffen:
I agree - git is here to serve us, not vice versa :-)
I've proposed creating server release branches,
similar to the exiting client release branches.
Hopefully this will satisfy everyone's needs.
-- David
On 8/7/2017 7:21 AM, Steffen Möller wrote:
Well, git makes one's "senses reeling
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
Well, git makes one's "senses reeling", at least when one has started a
career with CVS. Linus had helped us escape, and he possibly gets more
respect from me for that than for his kernel work. For me, it was the
git repository for BOINC _packaging_ that had forced me into it, long
before BOINC tra
Thanks for that last paragraph, Oliver. You put into words what has been
running through my mind since Friday.
-- Jord van der Elst.
On Mon, Aug 7, 2017 at 9:55 AM, Oliver Bock wrote:
> On 06/08/17 22:40 , David Anderson wrote:
> > Testing a feature in isolation is not the same as testing the
On 2017-08-06 22:40, David Anderson wrote:
Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
in particular the definition of "stable".
[...]
Testing a feature in isolation is not the same as testing the system.
Indeed.
But that doesn't mean that "testing in isolation" shouldn'
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
Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
in particular the definition of "stable".
I think you're laboring under a misapprehension.
Testing a feature in isolation is not the same as testing the system.
No one is advocating committing untested or buggy code into master.
How
On 04.08.17 23:17, David Anderson wrote:
On 7/21/2017 5:47 AM, Bernd Machenschalk wrote:
This might be one of the fundamental (pun intended) misunderstandings
here. It is the opposite of everything I ever heard or read, and I
think I know why:
How can one (expect to) fork a 'stable' branch
Hi David,
On 04/08/17 23:17, David Anderson wrote:
It's simple:
1) fork master, e.g. to client_release_xxx. It's not stable at this
point.
2) test client_release_xxx (e.g. using Alpha testers) fix bugs,
repeat. Now it's stable.
3) only backport bug fixes to client_release_xxx. It remains
On 7/21/2017 5:47 AM, Bernd Machenschalk wrote:
This might be one of the fundamental (pun intended) misunderstandings here. It is
the opposite of everything I ever heard or read, and I think I know why:
How can one (expect to) fork a 'stable' branch from an 'unstable' one? How can one
grow
Hi All,
I can see (good) arguments both ways - though now that the pace of
development is slowing, and the number of projects growing/projected
to grow, I would tend to err on the side of the 'stable' master-branch
model.
As regards a testing method, I could maybe suggest there is a specific
Hi David!
On 21.07.17 11:43, Bernd Machenschalk wrote:
Master is unstable in both models; releases are done from stable
branches.
This might be one of the fundamental (pun intended) misunderstandings
here. It is the opposite of everything I ever heard or read, and I think
I know why:
How
48 matches
Mail list logo
