> The canonical way of packaging for system install is to use PREFIX=/usr and
> then do
> make DESTDIR=/some/staging/directory install
Thanks.
Looks like waf has a --destdir option that works with the install command
and --prefix that works with configure.
--
These are my opinions. I hate
Hal Murray :
> Are you carefully monitoring things? Do you look at the graphs every day?
Not every day. I do often have ntpmons watching one pr more of them.
> What configurations are you testing? Pool? PPS? Is your network connection
> flakey? (WiFi can be a good test case.)
Yes to the f
Hal Murray :
>
> > I'd prefer to go to an accelerated 1.1
> > The main reason is that there isn't just one ntpq fix. ...
>
> "accelerated" is ambiguous. Do you mean release sooner than previously
> planned or reduced time between now/freeze and release bits being available?
The former.
> I
>> Your version of "pretty stable" doesn't match mine.
> Probably not. To a first approximation I judge "pretty stable" by the
> burn-in time on my Pis. If it runs for long periods of time on all six with
> no anomalies, it's stable.
I don't consider that to be much testing, but you didn't actua
> I'd prefer to go to an accelerated 1.1
> The main reason is that there isn't just one ntpq fix. ...
"accelerated" is ambiguous. Do you mean release sooner than previously
planned or reduced time between now/freeze and release bits being available?
I'd be happy to release now rather than J
On 12/06/2017 04:03 PM, Hal Murray via devel wrote:
Many years ago, a friend showed me an article in a bicycle magazine about how
to get ready for a race or big ride. It had all the expected things about
getting your bike ready. It also included ironing your shirt. ??? The idea
was that if
devel@ntpsec.org said:
> I have a different plan. I always write doc patches as part of my change
> commits; my discipline is to prevent code and docs from getting out of sync
> in the first place.
I agree that documentation should be kept up to date.
> I'm not opposed to giving the docs an occa
> If you're going to say "identify your customers: the plan has to specify how
> we can do that.
There is a large part of project management that depends upon the skill and
experience of the project manager. You won't get a crisp specification for
those areas.
The obvious example is "How long
Hal Murray :
> > Remember, Linux used to have stable-branch releases. It no longer does
> > because Linus noticed the same failure mode I did. When you start
> > cherry-picking onto a "safe" branch you increase the expected time to
> > discovery of any bugs on your unstable branch. This is not a
devel@ntpsec.org said:
> Remember, Linux used to have stable-branch releases. It no longer does
> because Linus noticed the same failure mode I did. When you start
> cherry-picking onto a "safe" branch you increase the expected time to
> discovery of any bugs on your unstable branch. This is no
Hal Murray :
>
> > If dev with merge-approver power pushes to a branch and then merges it, how
> > is the entailed risk any different from a direct push?
>
> We could add a policy that somebody else do the push, presumably after
> checking the code. With details of "check" TBD.
>
> How many o
> If dev with merge-approver power pushes to a branch and then merges it, how
> is the entailed risk any different from a direct push?
We could add a policy that somebody else do the push, presumably after
checking the code. With details of "check" TBD.
How many of your changes need to actual
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > I'd prefer to go to an accelerated 1.1
>
> So what exactly do you mean by "accelerated"?
We were vaguely planning on 1.1 in January.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet
Matthew Selsky via devel :
> OK, then let's put those several fixes on a branch from the 1.0 tag and
> release from there (if we're looking for a quick release).
>
> There's been too much churn in non-PLL code removal, waf changes for
> python install paths, etc, to mix chose changes with actual
Matthew Selsky via devel :
> On Wed, Dec 06, 2017 at 12:25:14PM -0500, Eric S. Raymond via devel wrote:
>
> > I have a different plan. I always write doc patches as part of my
> > change commits; my discipline is to prevent code and docs from getting out
> > of sync in the first place.
>
> Does
Hal Murray :
>
> e...@thyrsus.com said:
> > Well, normally it would be a longer freeze, but we're doing this to roll out
> > a bug fix on code that has been pretty stable.
>
> Your version of "pretty stable" doesn't match mine.
Probably not. To a first approximation I judge "pretty stable" by t
On Wed, Dec 06, 2017 at 12:25:14PM -0500, Eric S. Raymond via devel wrote:
> I have a different plan. I always write doc patches as part of my
> change commits; my discipline is to prevent code and docs from getting out
> of sync in the first place.
Does everyone on the project do that? This "p
Eric S. Raymond via devel writes:
> I'd prefer to go to an accelerated 1.1
So what exactly do you mean by "accelerated"?
> The main reason is that there isn't just one ntpq fix. There have been a
> whole bunch of small but user-visible and irritating bugs in ntpq
> reporting since 1.0 - we had
On Wed, Dec 06, 2017 at 12:14:18PM -0500, Eric S. Raymond wrote:
> Matthew Selsky via devel :
> > On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
> > >
> > > If you want to do a quick release, then we should backport critical
> > > fixes. I
> > > assume that turns into a b
Hal Murray via devel writes:
> How do they use it? Do they actually do a "make install" in the build
> environment, or somehow capture whatever the install step does?
The canonical way of packaging for system install is to use PREFIX=/usr
and then do
make DESTDIR=/some/staging/directory install
Hal Murray :
> There was some sort of document on the release process. Anybody remember
> where it lives?
It's in devel/pre-release.txt. I think you wrote it.
> In the short term, I think we have 2 options. One is to make a bug fix
> release with only a few lines of code changed. That doesn
Matthew Selsky via devel :
> On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
> >
> > If you want to do a quick release, then we should backport critical fixes.
> > I
> > assume that turns into a branch in git.
>
> Amen. We should release 1.0.1 that just includes the ntpq
On 12/06/2017 09:11 AM, Richard Laager via devel wrote:
Probably? The behavior was already correct for the distro package. Was
anything else broken?
For installs the only remaining problem is that for unknown reasons it
sometimes doesn't follow the PREFIX when installing the python libs.
-
On 12/06/2017 12:36 AM, Gary E. Miller wrote:
> On Tue, 5 Dec 2017 23:57:37 -0600
> Richard Laager via devel wrote:
>> On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote:
>>> I'm not clear why we care about the pip cases.
>>
>> I agree. If this matters, it can always be addressed later.
>
On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
>
> If you want to do a quick release, then we should backport critical fixes. I
> assume that turns into a branch in git.
Amen. We should release 1.0.1 that just includes the ntpq fix and the AWS fix
(and any other critica
On 12/05/2017 11:57 PM, Richard Laager via devel wrote:
From my reading of that wiki page, the distro-packaged Python uses
dist-packages whenever stock Python would use site-packages. This way,
if you install the distro Python package *and* Python from source, you
can install modules for each
Richard Laager via devel :
> On 12/05/2017 10:32 PM, Eric S. Raymond via devel wrote:
> > At least in RPM-land, they like to use the package's own make install
> > when possible. I sin't know about Debian packaging.
>
> Yes, it's ideal to use upstream's make install. Obviously, we packagers
> can
> Aha. This sounds like the beginning of something I just asked you to do
> privately - design an actual acceptance process for a release.
I'll be glad to work on that. Where does it fit in on the priorities? I'm
assuming not much will happen until after the release.
There was some sort of do
28 matches
Mail list logo
