Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dirk Meyer]

Hallo Julian H. Stacey,

> But if one stands on a broken system & needs to recover, some simple
> stock cc & sh tool/procedure with no dependencies is attractive, even if
> one has to coble something ones self.

I agree.
maybe you like to try:
$ less /usr/ports/ports-mgmt/pkg_jail/files/README

kind regards Dirk

- Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
- [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org]
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

On Tue, 27 Jun 2017 18:16:01 -0500, Mark Linimon
 wrote:

>On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote:
>> Since that's what I integrate for my dev use, I'd be happy to
>> take a zero'th-order cut at defining it, if nobody else wants to.
>
>Fine.  See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what
>I use.  I'm not particularly interested in maintaining it as a general
>set of files, but if someone can build on it, fine.

Okay, I'll hae a keik.

>
>> By "unnecessary", Mark, I mean the fact that the bits are not
>> controlled locally, and thus potentially change from moment to
>> moment such that it's impossible to guarantee that two people
>> building the same app with the same options on two different
>> days, or even hours, will get the same result.
>
>I don't understand this.
>
>The distinfo mechanism is the solution for this problem for released
>code.
>
>If people are relying on "whatever is in git at the moment" to
>mean "release", well then that's upstream not understanding what
>is meant by "release".  Either educated them or fork their code
>and become the new upstream.

No, I'm talking about how when trying to build a port, even if
using only the defaults, the process often fails to run to
completion.  

And the failure is nearly always because some glop of bits being
fetched from godknowswhere.edu has gone missing, or has been
upped and is now the wrong version as far as the makefile is
concerned, or has some other problem.  

Since I believe that 90% or more of our maintainers are
conscientious and build at least the default config, I can only
suppose, when the make fails, that somebody over at
godknowswhere.edu decided to do something ad-hoc, and that
"something" broke the build.  This happens so often that I don't
even try to build from ports any more ---my own work already
supplies more craziness than I can use.

>
>> Switching to a central repository model, where the bits are
>> fetched from around the globe only once per cycle, sanitised, and
>> thereafter read only from the repository, would drop the number
>> of file-not-founds and wrong-versions down pretty close to zero.
>
>Again, I simply don't understand this.

If we controlled the bits from which ports were built, then
nobody (I hope!!) would be changing them in an ad-hoc way, which
*should* make every build run to completion without
file-not-found etc.

>
>> >No one has ever done the work on "most minimal set of dependencies"
>> >in the ports tree -- and that's because it's hard work.  Add to that
>> >the fact that the technology has never supported partial checkouts
>> >and it complicates things.
>> 
>> No argument from me!   IMO a big contributor to the problem is
>> that the bits haven't been normalised and integrated into
>> libraries.  So the process is frankensteinean:  odds and bobs
>> dredged up wherever they can be found and stuck together in hope
>> that they'll cooperate.
>
>And this is where the hard work lies.
>
>By comparison, defining "which ports are canonical" is easy.
>
>IMHO.

I can only repeat that you'll get no argument from me! 

But that's the basic advantage of libraries:  do the hard work
once, benefit from it forever (fsvo "once" and "forever").   

Or do the work forever, and benefit each time only once.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 27.06.2017 15:24, scratch65...@att.net wrote:

[Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka
 wrote:


we could
start small with a just a handful of ports in a stable LTS (Long Term
Support) branch. Develop processes around maintaining them, get some
feedback about the effort of applying only security fixes, then add more
ports as required or as viable from the resources point of view. How
does that sound?


It sounds excellent, at least to me.

How many platform roles are seen as fbsd's metier?

Firewall?  Already handled.

Specialist workstations such as sound/video editing?  Maybe.  I
don't know enough about that to have an opinion.

Servers.  No question.  That's always been freebsd's best thing.
The number of ports to build a server-of-all-work is not large.
Unnecessarily complex and a source of uncontrolled errors, yes,
but not really *large* qua large.


It really depends. For example only www/gitlab needed 400 ports (!) and 
its a while i checked.

Without a defined list of supported software this is only wishing ;)

Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 26.06.2017 21:33, Grzegorz Junka wrote:

On 26/06/2017 07:24, Torsten Zuehlsdorff wrote:

Aloha David,


I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.


The discussions did go on for a while, but lets get more technical. 
While i can understand your use case, it raises various questions:


- How should be EOL-Software handled? For example PHP 5.6, Typo3 7, 
PostgreSQL 9.2 and many more will expire long before FreeBSD 11 
expires but are still valid (or even default version) when created. 
Since the versions are frozen, how should - at least- security issues 
handled?
[Yes, i read that a user can switch at its own risk to another branch, 
but lets assume he is very fine with the version (because i have such 
customer)]


- How should be new dependencies handled? GitLab for example sometimes 
*requieres* updates of its dependencies in order to fix security issues.


- Same as above: how should be dropped dependencies handled? In worst 
case we need to maintain them for nearly 5 years, but nobody (should) 
use them


- How to resolve conflicts? I mentioned GitLab above and now realize, 
that sometimes the GitLab update breaks for example www/redmine 
because it depends at other versions than GitLab.


- Where do get the fixes from? We have around 26.000 ports which needs 
fixes in worst case


- How to handle for example security issues only fixed through an 
update? Which such a long time between "updates" it gets very very 
hard to port/get/write patches in fast developing software. Wordpress 
or Gitlab are typical examples with thousands of lines in code-changes 
every update


- How to make the customer clear, that complains about the software 
(old, outdated, missing features, unresolved bugs, etc) are intentional?


- Where to archive the distfiles? Sometimes upstream completely remove 
them from everywhere they can.


And last: how to make updates from FreeBSD version to version easier? 
Many user already have problems with single major updates. From my 
experiences in Windows or Ubuntu LTS usages with such or very similar 
version handling: the update, even of the OS, is pushed as far away as 
possible, because of the big amount of work required, since everything 
needs to checked/updated/changed.


I have a hard time to image, that is handled in another way by you. So 
if you can me give more insight about your use-case i would be happy 
to read it for a better understanding.


I have various customer requiring (and paying for) very old software 
(for example still PHP 5.3). So i know some of there motivations, 
which boils every time down to "its to expensive to upgrade our 
software" [but they don't mean expensive in money]. So maybe we can 
make something happen. 


I understand a stable ports branch would be required by specific 
applications (of the FreeBSD system), e.g. data centers, bespoke private 
solutions, home servers. Therefore not all 26.000 ports would need to be 
security-patched. In fact, I believe it would be viable to determine a 
thousand or two of ports mostly used in those environments and commit to 
patch only those.


Yes, but even with a subset of the ports-tree neither of the above 
problems is addressed!


Even RedHat, which is a model example, doesn't commit to maintain all 
packages, just a selected set of them. In the similar fashion to having 
Tier 1, Tier 2 and Tier 3 supported platforms for FreeBSD, we could 
start small with a just a handful of ports in a stable LTS (Long Term 
Support) branch. Develop processes around maintaining them, get some 
feedback about the effort of applying only security fixes, then add more 
ports as required or as viable from the resources point of view. How 
does that sound?


This didn't address any of the issues mentioned above. Nor from other 
threads.


But to be clear: since i already do such things (on a much smaller 
scale) i have no problem with this idea. But since i'm already get paid 
and know the work behind it, i wont do it for free.
Even do setup a minimal QA infrastructure needs money and maintenance 
and just build-tests are not enough.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Mark Linimon:

> On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote:
> > raising the possibility of building for other targets.

> Which is very much not hardly even the same as "they are being resistant
> to change".  In fact, about as far away from it as is possible to get.

> "techinically possible" != "feasible in the immediate future".

> I feel like I'm repeating myself in this thread, again.

> mcl

A lot of pkgsrc users, perheps the majority, use architecture either i386 or 
amd64 (I have no statistics).

FreeBSD also supports many architectures, not as many as NetBSD, but some where 
there is no Ada compiler, and no LLVM/clang either.

Some of the architectures supported by NetBSD are near-extinct now, acorn26 for 
one, and would not be prime targets for pkgsrc development, nobody is going to 
care about lack of an Ada compiler.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 27/06/2017 17:45, Mark Linimon wrote:

On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:

The number of ports to build a server-of-all-work is not large.

Now the problem is getting people to agree on exactly what that
subset is.


I think this part is fairly easy. We can start with ports for which 
maintainers agree to provide security fixes to the stable branch or 
artificially limit the number and ask people to vote for their 
favourites. Another point for consideration is to firstly consider ports 
with smaller amount of dependencies so that there is less work in 
maintaining them.

No one has ever done the work on "most minimal set of dependencies"
in the ports tree -- and that's because it's hard work.  Add to that
the fact that the technology has never supported partial checkouts
and it complicates things.


Yes, but you need to start somewhere. Otherwise it will remain as 
occasional rant. Clearly starting with 26,000 isn't an option. Then 
starting with small number of ports and learning how to overcome these 
difficulties is best we can do.



tl;dr: I do have long-time experience building subsets of the ports
tree and in my experience it's harder than people think, once you
get beyond a few dozen targets.



I think the hardest part is to agree on a set that is not too difficult 
to maintain but still useful so that people will try to actually install 
systems using them.


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 04:53:36PM -0400, scratch65...@att.net wrote:
> Since that's what I integrate for my dev use, I'd be happy to
> take a zero'th-order cut at defining it, if nobody else wants to.

Fine.  See http://www.lonesome.com/FreeBSD/poudriere/subsets/ for what
I use.  I'm not particularly interested in maintaining it as a general
set of files, but if someone can build on it, fine.

> By "unnecessary", Mark, I mean the fact that the bits are not
> controlled locally, and thus potentially change from moment to
> moment such that it's impossible to guarantee that two people
> building the same app with the same options on two different
> days, or even hours, will get the same result.

I don't understand this.

The distinfo mechanism is the solution for this problem for released
code.

If people are relying on "whatever is in git at the moment" to
mean "release", well then that's upstream not understanding what
is meant by "release".  Either educated them or fork their code
and become the new upstream.

> Switching to a central repository model, where the bits are
> fetched from around the globe only once per cycle, sanitised, and
> thereafter read only from the repository, would drop the number
> of file-not-founds and wrong-versions down pretty close to zero.

Again, I simply don't understand this.

> >No one has ever done the work on "most minimal set of dependencies"
> >in the ports tree -- and that's because it's hard work.  Add to that
> >the fact that the technology has never supported partial checkouts
> >and it complicates things.
> 
> No argument from me!   IMO a big contributor to the problem is
> that the bits haven't been normalised and integrated into
> libraries.  So the process is frankensteinean:  odds and bobs
> dredged up wherever they can be found and stuck together in hope
> that they'll cooperate.

And this is where the hard work lies.

By comparison, defining "which ports are canonical" is easy.

IMHO.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 09:01:39PM +, Thomas Mueller wrote:
> raising the possibility of building for other targets.

Which is very much not hardly even the same as "they are being resistant
to change".  In fact, about as far away from it as is possible to get.

"techinically possible" != "feasible in the immediate future".

I feel like I'm repeating myself in this thread, again.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Mark Linimon:

> Remember that NetBSD runs on dozens of targets*, of which only two support
> Ada AFAIK.

> mcl

> * http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1/

I follow http://releng.netbsd.org/cgi-bin/builds.cgi

which shows 72 targets for HEAD, 67 targets for netbsd-7 and netbsd-8, 60 
targets for netbsd-6.

Ada, developed by the US Department of Defense, was not originally for amd64 
and i386.

A large part of the problem is that building Ada requires a preexisting GNAT.

Full GCC suite includes Ada, and is capable of cross-compilation, raising the 
possibility of building for other targets.

I can not say with authority which targets would succeed.

Dragonlace.net shows a port for FreeBSD aarch64.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Tue, 27 Jun 2017 12:45:34 -0500, Mark Linimon
 wrote:

>On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:
>> The number of ports to build a server-of-all-work is not large.
>
>Now the problem is getting people to agree on exactly what that
>subset is.

Since that's what I integrate for my dev use, I'd be happy to
take a zero'th-order cut at defining it, if nobody else wants to.

>
>If there is interest, I can provide the examples and code I use
>whenever I start up a new machine here at the house, e.g. powerpc64,
>sparc64, etc.  And we'll see how close to agreement people can get.

Sounds good t'me!  

>
>(Yes, I'm quite skeptical.)
>
>> Unnecessarily complex and a source of uncontrolled errors, yes,
>
>One person's "unnecessary" is another person's "necessary".

By "unnecessary", Mark, I mean the fact that the bits are not
controlled locally, and thus potentially change from moment to
moment such that it's impossible to guarantee that two people
building the same app with the same options on two different
days, or even hours, will get the same result.

Switching to a central repository model, where the bits are
fetched from around the globe only once per cycle, sanitised, and
thereafter read only from the repository, would drop the number
of file-not-founds and wrong-versions down pretty close to zero.

>
>> Specialist workstations such as sound/video editing?  Maybe.
>
>You'll immediately go from a few hundred ports to a few thousand ports.
>
I'm happy to take your word for it, because I've no clue.  I
wonder whether the most important subset could be determined by
survey.  Any views on that?

>No one has ever done the work on "most minimal set of dependencies"
>in the ports tree -- and that's because it's hard work.  Add to that
>the fact that the technology has never supported partial checkouts
>and it complicates things.

No argument from me!   IMO a big contributor to the problem is
that the bits haven't been normalised and integrated into
libraries.  So the process is frankensteinean:  odds and bobs
dredged up wherever they can be found and stuck together in hope
that they'll cooperate.  Just looking at the stuff that goes into
Firefox made my blood run cold, and completely explained (fsvo
explained) where all the problems come from with that app.

>
>tl;dr: I do have long-time experience building subsets of the ports
>tree and in my experience it's harder than people think, once you
>get beyond a few dozen targets.

I don't doubt that even  slightly.   But I do think the magnitude
could be at least reduced by moving toward normalised bits.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 07:37:22AM +, Thomas Mueller wrote:
> It seems NetBSD pkgsrc people are not catching on, preferring to stay
> with the clumsy pkgsrc tools: creatures of habit, reluctant to change.

Remember that NetBSD runs on dozens of targets*, of which only two support
Ada AFAIK.

mcl

* http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:
> The number of ports to build a server-of-all-work is not large.

Now the problem is getting people to agree on exactly what that
subset is.

If there is interest, I can provide the examples and code I use
whenever I start up a new machine here at the house, e.g. powerpc64,
sparc64, etc.  And we'll see how close to agreement people can get.

(Yes, I'm quite skeptical.)

> Unnecessarily complex and a source of uncontrolled errors, yes,

One person's "unnecessary" is another person's "necessary".

> Specialist workstations such as sound/video editing?  Maybe.

You'll immediately go from a few hundred ports to a few thousand ports.

No one has ever done the work on "most minimal set of dependencies"
in the ports tree -- and that's because it's hard work.  Add to that
the fact that the technology has never supported partial checkouts
and it complicates things.

tl;dr: I do have long-time experience building subsets of the ports
tree and in my experience it's harder than people think, once you
get beyond a few dozen targets.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Mon, 26 Jun 2017 19:33:50 +, Grzegorz Junka
 wrote:

>we could 
>start small with a just a handful of ports in a stable LTS (Long Term 
>Support) branch. Develop processes around maintaining them, get some 
>feedback about the effort of applying only security fixes, then add more 
>ports as required or as viable from the resources point of view. How 
>does that sound?

It sounds excellent, at least to me.  

How many platform roles are seen as fbsd's metier?

Firewall?  Already handled.

Specialist workstations such as sound/video editing?  Maybe.  I
don't know enough about that to have an opinion.

Servers.  No question.  That's always been freebsd's best thing.
The number of ports to build a server-of-all-work is not large.
Unnecessarily complex and a source of uncontrolled errors, yes,
but not really *large* qua large.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian H. Stacey]

"Thomas Mueller" wrote:
> from Dewayne Geraghty:
> 
> > Synth is very good.  It builds upon pkg and is way less complicated that
> > poudriere.

I dont know the relative dependencies counts for both synth & poudriere,
but I suspect synth is bigger ?
  ( I have a messed up current here where loads of ports break, I
  tried to build synth to then recover other ports, but synth broke
  deep, building some gcc, & I have a working poudriere.)

If one has a good stable platform, then a nice maintainer that does
chroot/jail elegantly with lots of features is probably attractive,
& dependency count not a worry.

But if one stands on a broken system & needs to recover, some simple
stock cc & sh tool/procedure with no dependencies is attractive, even if
one has to coble something ones self.

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#700k_stolen_votes
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Dewayne Geraghty:

> Synth is very good.  It builds upon pkg and is way less complicated that
> poudriere.
 
> Unfortunately John Marino was unceremoniously removed from committing to
> FreeBSD, and its is uncertain whether he'll continue to support synth on
> FreeBSD.  (He supports DragonflyBSD.  :)

I remember reading about this falling-out.  Are others in FreeBSD ports taking 
over and continuing support and updates for synth?

Does John Marino still support NetBSD pkgsrc with synth?  It seems NetBSD 
pkgsrc people are not catching on, preferring to stay with the clumsy pkgsrc 
tools: creatures of habit, reluctant to change.

I tried the live/installation DragonFlyBSD USB-stick image, but it had 
problems: no Internet access, drivers missing or nonworking, and my last try 
didn't boot.  Also it couldn't (previous tries) mount any FreeBSD or NetBSD 
partition, and FreeBSD and NetBSD couldn't mount/read the DragonFlyBSD USB 
stick even with UFS as opposed to Hammer file system.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/26/2017 00:27, Guido Falsi wrote:

I only partly agree with what you say, but anyway insisting on the
mailing lists with individual committers, and defending a general idea
ignoring all the details, dismissing the actual problems in the detailed
implementation that are raised by committers is not going to get much done.


I agree that empirical evidence would suggest this to be true.


It has also been suggested here to write a full blown, planned and
though out proposal to be submitted via the new "FreeBSD Community
Process" [1], which could be much more effective.


Perhaps. I'm more of a 'get stuff done' kind of person than an RFC 
writer myself, but I'd like to see someone take a shot at it.



I'd say the difficult part in such a problem is not in the idea but in
the boring details of it's implementation and long term maintenance.


Actually I see the difficult part as how to solve the conflicting needs 
of this community. There appear to be two ideas: bleeding edge ports and 
stable ports. These are somewhat mutually exclusive and exacerbated by 
the need for security patches for the latter. I "solve" this problem by 
using quarterlies and running builds often, but it's not necessarily the 
best way.


I'd personally envision a "version" knob for ports, so you could 
explicitly specify the exact version of software you wanted to build; 
kind of like the options knobs are now. The work involved in making each 
value of that knob actually build is probably prohibitive, but it would 
allow various people to focus on the versions that matter to them. This 
would also limit discussions like these to specific support for specific 
ports, but those happen anyway so at least this particular

discussion would become moot.
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

A generous person may not have wisdom. Unlike others,
this person has the means to gain wisdom.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

Aloha David,


I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.


The discussions did go on for a while, but lets get more technical. 
While i can understand your use case, it raises various questions:


- How should be EOL-Software handled? For example PHP 5.6, Typo3 7, 
PostgreSQL 9.2 and many more will expire long before FreeBSD 11 expires 
but are still valid (or even default version) when created. Since the 
versions are frozen, how should - at least- security issues handled?
[Yes, i read that a user can switch at its own risk to another branch, 
but lets assume he is very fine with the version (because i have such 
customer)]


- How should be new dependencies handled? GitLab for example sometimes 
*requieres* updates of its dependencies in order to fix security issues.


- Same as above: how should be dropped dependencies handled? In worst 
case we need to maintain them for nearly 5 years, but nobody (should) 
use them


- How to resolve conflicts? I mentioned GitLab above and now realize, 
that sometimes the GitLab update breaks for example www/redmine because 
it depends at other versions than GitLab.


- Where do get the fixes from? We have around 26.000 ports which needs 
fixes in worst case


- How to handle for example security issues only fixed through an 
update? Which such a long time between "updates" it gets very very hard 
to port/get/write patches in fast developing software. Wordpress or 
Gitlab are typical examples with thousands of lines in code-changes 
every update


- How to make the customer clear, that complains about the software 
(old, outdated, missing features, unresolved bugs, etc) are intentional?


- Where to archive the distfiles? Sometimes upstream completely remove 
them from everywhere they can.


And last: how to make updates from FreeBSD version to version easier? 
Many user already have problems with single major updates. From my 
experiences in Windows or Ubuntu LTS usages with such or very similar 
version handling: the update, even of the OS, is pushed as far away as 
possible, because of the big amount of work required, since everything 
needs to checked/updated/changed.


I have a hard time to image, that is handled in another way by you. So 
if you can me give more insight about your use-case i would be happy to 
read it for a better understanding.


I have various customer requiring (and paying for) very old software 
(for example still PHP 5.3). So i know some of there motivations, which 
boils every time down to "its to expensive to upgrade our software" [but 
they don't mean expensive in money]. So maybe we can make something happen.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Franco Fichtner]

> On 26. Jun 2017, at 9:43 AM, Kurt Jaeger  wrote:
> 
>> Thus, in some cases, people demand or insist because they want something 
>> they either cannot accomplish themselves, or cannot accomplish in the 
>> limited time they have. As far as I have observed, you can't even -pay- 
>> the ports experts to do something you might want.
> 
> You can discuss the general idea with the foundation. Then give them
> the money they estimate for the feature. They'll easily find folks doing it.
> It just won't be cheap.

How about this: add more volunteers to begin with, more free resources for
any useful work.  With the right project leadership it'll do great.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Kurt Jaeger]

Hi!

> Thus, in some cases, people demand or insist because they want something 
> they either cannot accomplish themselves, or cannot accomplish in the 
> limited time they have. As far as I have observed, you can't even -pay- 
> the ports experts to do something you might want.

You can discuss the general idea with the foundation. Then give them
the money they estimate for the feature. They'll easily find folks doing it.
It just won't be cheap.

I guesstimate that you need at least 2 person-years to implement a working
scheme that works within the current framework.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Guido Falsi]

On 06/26/17 09:27, Guido Falsi wrote:
> I'd say the difficult part in such a problem is not in the idea but in
> the boring details of it's implementation and long term maintenance.
> 

I forgot one important piece of information:

Any project that requires full dedication from all committers to a
"stable/release ports branch" is bound to be criticized to death and
anyway bound to failure (IMHO). Any such proposal should identify some
volunteer party with well defined roles. Remember ports work is all
volunteer, you can't impose any work on any party!

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Guido Falsi]

On 06/26/17 00:32, Dave Hayes wrote:
> On 06/23/2017 01:53, Guido Falsi wrote:
>> If your model works fine I'm quite sure the FreeBSD community and
>> project will be quite happy to embrace it.
> ...
>> I cannot think of a better way to show there actually is no manpower
> problem than creating a working example of such a workflow maintained by
> just a few people with little effort, as you said repeatedly.
> ...
>> On other hand demanding and/or insisting that others implement your idea
>> when they clearly disagree with you is not very constructive.
> 
> The fallacy in your suggestion to "do it yourself" is that the others
> who are actually working and committing on ports are far more efficient
> at implementing these ideas than the rest of us.
> 
> I've never seen someone who says "do it yourself if you want it
> different" actually take into account that the expertise and experience
> of the people currently doing it result in a far lower manpower cost,
> sometimes by orders of magnitude.

I only partly agree with what you say, but anyway insisting on the
mailing lists with individual committers, and defending a general idea
ignoring all the details, dismissing the actual problems in the detailed
implementation that are raised by committers is not going to get much done.

It has also been suggested here to write a full blown, planned and
though out proposal to be submitted via the new "FreeBSD Community
Process" [1], which could be much more effective.

Such a proposal should specify required resources with a decent degree
os precision, procedures, tools and instruments needed and also has to
address what is to be done in all the corner cases that can be foreseen
too(providing examples of such corner cases is besides the point here,
but there are many).

I think is someone really wants something different from the ports tree
than what is provided now the effort to exactly describe it is the only
viable way to get something done.
> 
> To be absolutely clear, I'm not demanding or insisting on anything here
> out of ports maintainers or FreeBSD. I can and do support myself, when I
> am able. I'm merely pointing out ideas which may not be immediately
> visible to the people in this thread.

The what you need to do, being a full blown implementation too much for
a single person, is write out a complete proposal and submit it for
review. A general idea for a "stable ports branch" or "release ports
branches" is too much generic and can attract only criticism, because
most committers have already had such generic ideas and dismissed it due
to the many problems that would come from it (quarterlies show some of
those). But maybe you can build a better proposal which avoids or solves
those problems.

I'd say the difficult part in such a problem is not in the idea but in
the boring details of it's implementation and long term maintenance.

[1] https://github.com/freebsd/fcp/blob/master/fcp-.md

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/23/2017 01:53, Guido Falsi wrote:

If your model works fine I'm quite sure the FreeBSD community and
project will be quite happy to embrace it.

...
> I cannot think of a better way to show there actually is no manpower 
problem than creating a working example of such a workflow maintained by 
just a few people with little effort, as you said repeatedly.

...

On other hand demanding and/or insisting that others implement your idea
when they clearly disagree with you is not very constructive.


The fallacy in your suggestion to "do it yourself" is that the others 
who are actually working and committing on ports are far more efficient 
at implementing these ideas than the rest of us.


I've never seen someone who says "do it yourself if you want it 
different" actually take into account that the expertise and experience 
of the people currently doing it result in a far lower manpower cost, 
sometimes by orders of magnitude.


Thus, in some cases, people demand or insist because they want something 
they either cannot accomplish themselves, or cannot accomplish in the 
limited time they have. As far as I have observed, you can't even -pay- 
the ports experts to do something you might want. If you do not have 
this time or expertise, the only recourses left are: demand, insist, 
request, plead, or attempt to logically convince.


As I see it, the emotions you see people expressing don't come as much 
from "not having their own way" as it does from being forced to adopt 
someone else's way. Looking at just that idea, the situation is not 
really that much different from using Microsoft and Apple; you take what 
they give you or go use something else. I think there's a general 
perception that open source is not supposed to be like that so much, but 
I think we all know differently here.


To be absolutely clear, I'm not demanding or insisting on anything here 
out of ports maintainers or FreeBSD. I can and do support myself, when I 
am able. I'm merely pointing out ideas which may not be immediately 
visible to the people in this thread.

--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

In a dream, Nasrudin saw himself being counted out
coins. When there were nine silver pieces in his hand, the
invisible donor stopped giving them.  Nasrudin shouted, "I
must have ten!" so loudly that he woke himself up.  Finding
all the money gone he closed his eyes again and said. "All
right, then, give them back. I'll take the nine."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Are there any advantages of using pkg instead of pkgsrc on FreeBSD?
Instead of having branches by OS version, would having ports LTS branches
independent of the base system be a better solution?
Grzegorz

It looks like you might have misunderstood something I said about pkgsrc.

I use pkg with FreeBSD ports on FreeBSD, but my interest in pkgsrc and 
pkgsrc-synth is for NetBSD.

Working with pkgsrc on NetBSD convinces me that they need to import portupgrade 
and/or portmaster from FreeBSD, maybe synth will be better?

Pkgsrc is awkward dealing with packages whose names have changes or branched.

Ports LTS branches, is that Long Term Service?  I don't really understand that 
question.

Tom



First question: Sorry, I used a mental shortcut without explaining. I 
imagined that because both pkg and pkgsrc support FreeBSD, the effort of 
maintaining both could be combined, and pkgsrc seemed to be superior 
since it also supports other OSes. I also assumed that that has been 
considered before. So, because pkg hasn't been replaced by pkgsrc, there 
must be some advantages of using pkg on FreeBSD as opposed to using 
pkgsrc. My question was about these.


LTS indeed is Long Term Support. In short, there is a branch (or 
branches) not tied to any specific OS release but can be dependent on a 
specific OS release (e.g. 11.0 as minimum) in which application versions 
don't change as often as in the current branch. It would mostly 
incorporate security fixes. Now, a question if the versions shouldn't 
change for the duration of the LTS branch or if small version changes 
are allowed is a secondary issue. What I am trying to determine if 
having that branch/es would fulfil the requirement of many people on 
this list of having a more stable ports tree (where branches by OS 
versions was one of the proposed solutions).


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Michelle Sullivan]

Martin Waschbüsch wrote:

Am 23.06.2017 um 23:53 schrieb Michelle Sullivan :

Matt Smith wrote:

I use FreeBSD *precisely* because it mostly keeps up with the latest stable 
versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 
etc. It's usually impossible to do this with linux unless you install things 
directly from source.

And me I came to FreeBSD because it was security conscious but not latest and 
greatest or nothing... well not strictly true, P Vixie forced me into trying 
it.. but I changed from Linux to FreeBSD across my entire product because of 
stability... which doesn't exist in the same way now (and hasn't since 
2013ish)..

FWIW, personally, I never perceived statements about FreeBSD's stability to 
extend beyond the scope of the (complete) OS itself.


There in lies a problem..  Something happened, now the OS is not as 
stable, as for a 'installed the CD how long before a reboot' is it, but 
how often do we *have* to upgrade because of a security issue.. seems 
like every 5 minutes now... ports (some of them) do form part of the 
OS... if the ports tree stops working on older versions of the OS then 
you *have* to upgrade.



I always regarded ports very much as a convenience. pkg even more so.


I don't consider pkg at all.  Ports are partly.




I upgrade my ports/packages via poudriere every single day which mostly just 
takes 2 minutes of my time as usually that results in maybe one or two packages 
being updated at a time. I see this as a positive thing rather than doing one 
massive huge upgrade every 3 months.

Currently have 87 servers located across 7 continents, all in production 
processing incoming spam at the millions per day, and serving DNS requests at a 
rate of over 70,000 queries per second (averaged over a week)... you can't just 
f**k with that.  Patches have to be evaluated, tested, built and regression 
tested


My personal conclusion is that if I need to ensure that issues (especially 
security fixes) are dealt with in a timely manner then I have to do the 
patching, testing, evaluating, etc. myself.


Mostly agreed... depends on your definition of  'do the patching 
yourself'.. if you mean taking patches applying them yourself, then yes 
100% agree, if you mean developing the patch yourself in whole or in 
part... no.



After all, even if all that was thoroughly done by upstream, port maintainer, 
etc., who’s to say my specific setup and config won’t bring issues to light 
their testing didn’t?


100% with you.



--
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

> > I personally can't see the rationale of many OS version branches of ports: 
> > far too much work.

> > I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
> > order, considering that pkgsrc has been ported to many OSes besides NetBSD.

> > Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
> > FreeBSD, Linux, etc.

> > I only follow the current branch of FreeBSD ports and pkgsrc, though now I 
> > have also become interested in pkgsrc-synth.

> Tom

> Are there any advantages of using pkg instead of pkgsrc on FreeBSD?

> Instead of having branches by OS version, would having ports LTS branches
> independent of the base system be a better solution?

> Grzegorz

It looks like you might have misunderstood something I said about pkgsrc.

I use pkg with FreeBSD ports on FreeBSD, but my interest in pkgsrc and 
pkgsrc-synth is for NetBSD.

Working with pkgsrc on NetBSD convinces me that they need to import portupgrade 
and/or portmaster from FreeBSD, maybe synth will be better?

Pkgsrc is awkward dealing with packages whose names have changes or branched.

Ports LTS branches, is that Long Term Service?  I don't really understand that 
question.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Fine. Considering that maintainers already apply patches to the latest
quarterly branch. If there were to be OS version branches, it would
mean that maintainers apart from what they are doing now would
additionally need to apply selected patches to those OS version
branches?

"OS version branches" would be a complete waste of time and resources, and it
would remove some level of separation/independence between the base and ports.
The crux of the problem here is so called "stable ports", not necessarily
tying them to the life cycle of a base release. It doesn't make sense to tie
version of a port to the base release. Especially with the new releng support
schedule that would mean 5 years per major version which is quite a lot.

(snip)

I personally can't see the rationale of many OS version branches of ports: far 
too much work.

I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
order, considering that pkgsrc has been ported to many OSes besides NetBSD.

Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
FreeBSD, Linux, etc.

I only follow the current branch of FreeBSD ports and pkgsrc, though now I have 
also become interested in pkgsrc-synth.

Tom



Are there any advantages of using pkg instead of pkgsrc on FreeBSD?

Instead of having branches by OS version, would having ports LTS 
branches independent of the base system be a better solution?


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Thomas Mueller]

from Vlad K:

> On 2017-06-23 23:09, Grzegorz Junka wrote:

> > Fine. Considering that maintainers already apply patches to the latest
> > quarterly branch. If there were to be OS version branches, it would
> > mean that maintainers apart from what they are doing now would
> > additionally need to apply selected patches to those OS version
> > branches?

> "OS version branches" would be a complete waste of time and resources, and it
> would remove some level of separation/independence between the base and ports.

> The crux of the problem here is so called "stable ports", not necessarily
> tying them to the life cycle of a base release. It doesn't make sense to tie
> version of a port to the base release. Especially with the new releng support
> schedule that would mean 5 years per major version which is quite a lot.
(snip)

I personally can't see the rationale of many OS version branches of ports: far 
too much work.

I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
order, considering that pkgsrc has been ported to many OSes besides NetBSD.

Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
FreeBSD, Linux, etc.

I only follow the current branch of FreeBSD ports and pkgsrc, though now I have 
also become interested in pkgsrc-synth.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Martin Waschbüsch]

> Am 23.06.2017 um 23:53 schrieb Michelle Sullivan :
> 
> Matt Smith wrote:
>> 
>> I use FreeBSD *precisely* because it mostly keeps up with the latest stable 
>> versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, libressl 2.5 
>> etc. It's usually impossible to do this with linux unless you install things 
>> directly from source.
> 
> And me I came to FreeBSD because it was security conscious but not latest and 
> greatest or nothing... well not strictly true, P Vixie forced me into trying 
> it.. but I changed from Linux to FreeBSD across my entire product because of 
> stability... which doesn't exist in the same way now (and hasn't since 
> 2013ish)..

FWIW, personally, I never perceived statements about FreeBSD's stability to 
extend beyond the scope of the (complete) OS itself.
I always regarded ports very much as a convenience. pkg even more so.

>> I upgrade my ports/packages via poudriere every single day which mostly just 
>> takes 2 minutes of my time as usually that results in maybe one or two 
>> packages being updated at a time. I see this as a positive thing rather than 
>> doing one massive huge upgrade every 3 months.
> Currently have 87 servers located across 7 continents, all in production 
> processing incoming spam at the millions per day, and serving DNS requests at 
> a rate of over 70,000 queries per second (averaged over a week)... you can't 
> just f**k with that.  Patches have to be evaluated, tested, built and 
> regression tested


My personal conclusion is that if I need to ensure that issues (especially 
security fixes) are dealt with in a timely manner then I have to do the 
patching, testing, evaluating, etc. myself.
After all, even if all that was thoroughly done by upstream, port maintainer, 
etc., who’s to say my specific setup and config won’t bring issues to light 
their testing didn’t?

Just my two cents.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Michelle Sullivan]

Matt Smith wrote:


I use FreeBSD *precisely* because it mostly keeps up with the latest 
stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, 
libressl 2.5 etc. It's usually impossible to do this with linux unless 
you install things directly from source.


And me I came to FreeBSD because it was security conscious but not 
latest and greatest or nothing... well not strictly true, P Vixie forced 
me into trying it.. but I changed from Linux to FreeBSD across my entire 
product because of stability... which doesn't exist in the same way now 
(and hasn't since 2013ish)..


Running postfix 2.9, pgsql 9.4 (8.4 in some places but they are top 
priority to upgrade if I can keep up with security issues everywhere 
else) openssl 1.0.2 and Apache 2.4 (.26 just upgraded myself)...





I upgrade my ports/packages via poudriere every single day which 
mostly just takes 2 minutes of my time as usually that results in 
maybe one or two packages being updated at a time. I see this as a 
positive thing rather than doing one massive huge upgrade every 3 months.


Currently have 87 servers located across 7 continents, all in production 
processing incoming spam at the millions per day, and serving DNS 
requests at a rate of over 70,000 queries per second (averaged over a 
week)... you can't just f**k with that.  Patches have to be evaluated, 
tested, built and regression tested



--
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Vlad K.]

On 2017-06-23 23:09, Grzegorz Junka wrote:


Fine. Considering that maintainers already apply patches to the latest
quarterly branch. If there were to be OS version branches, it would
mean that maintainers apart from what they are doing now would
additionally need to apply selected patches to those OS version
branches?


"OS version branches" would be a complete waste of time and resources, 
and it would remove some level of separation/independence between the 
base and ports.


The crux of the problem here is so called "stable ports", not 
necessarily tying them to the life cycle of a base release. It doesn't 
make sense to tie version of a port to the base release. Especially with 
the new releng support schedule that would mean 5 years per major 
version which is quite a lot.


RHEL/CentOS achieve that with:

1. paid maintainers
2. far less packages to maintain
3. strictly supported set of enabled features/packages

Even Canonical is supporting far less packages in their Ubuntu 
"Universe" (officially supported repo), while tens of thousands of other 
packages are "Community support".


So that's two ecosystems with vastly more users and contributors. 
They're also ecosystems with strict policies in place so "volunteer 
time" excuse does not apply, the maintainers are expected to do certain 
things and to it as the policy prescribes it. From what I gather, 
something like this would be impossible in FreeBSD because nobody is 
"required" to do anything, "we're all volunteers" I've been told.


Another part of such a policy is commitment to maintain the package for 
the duration of release (in Debian/Ubuntu), to the extent of packages 
being removed if the maintainer is not committing as promised (which 
usually happens during freezes of next stable).


So the only solution is to maintain stable ports for the duration of 
their upstream life cycle. The problem was with node, so fine, support 
www/node6 for as long as upstream supports it. Anything else would 
require tremendous amount of work to cherry pick and backport from a 
codebase that is increasingly changing and making it much more difficult 
with each upstream release. if "www/node" is not obvious enough to mean 
latest node, then rename it to node-latest. As in this case (the 
original post of this thread), reading UPDATING would've sufficed to 
avoid any problems.


Another example is Roundcube. We have bumped roundcube to 1.2 last year. 
Personally I balked at this and kept 1.1 around in my local tree until I 
properly tested 1.2. Another example was irssi that was bumped from 
0.8.x to 1.x (and in quarterly even, and approved by ports-secteam!), 
breaking some plugins in the process.


But, given that example, under this new "stable ports" regime, there 
would be mail/roundcube11, mail/roundcube12 etc... Especially since the 
upstream continues LTS of older versions.


Again, nothing prevents the maintainers from doing it right now. No 
special project or repo is needed except the maintainers' will and time 
to do so, which is obviously lacking.


And I'll join the concerns expressed earlier, about people who are not 
familiar with a port, maintaining it. I've seen that cause breakages, 
because the committer doing the change does not understand the port, and 
am vehemently against it.




--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Michelle Sullivan]

Julian Elischer wrote:


(*) From my experience, the best way to cope with openssl is to have 
everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).


Agree on previous parts of your message but have to say 'no' here... 
Ports OpenSSL is the way to go.. because of the FreeBSD policy "we won't 
change the ABI" one of the reasons for no having 9.4 was OpenSSL 0.9.8 
was EoLd and there were/are bugs unpatched Thing is its a perfect 
example of why OpenSSL should not be bundled into the OS... but then you 
can't rely on the ports system because of the drive to change it.


Rock and a hard place comes to mind...  Problem is you have @freebsd.org 
email holder saying, "we don't get paid for this so we'll do it our 
way... pay us to do it your way or do it yourself" vs the users, that 
are shouting, "come on guys we can't keep up, we need stability, we're 
not using this as a desktop here"


And both sides are diametrically opposed and steadfast to the point of 
zealous-ism...


--
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Can't you just create the branch yourself? It's open source. You just 
clone it and can keep it in Github for free. Then you can apply 
security patches to just the applications you need yourself. If it's 
too difficult you can hire people to apply just specific patches. 
With Github pull requests it's deadly easy. I am sure that if you 
asked maintainers to do the patching for a financial incentive they 
would mind doing it.
I actually explained it..  We do not have the people who understand 
all those ports.
if there is a port hat gets a fix, one assumes there is a maintainer 
who at least understands that port a bit.

I would feel more comfortable if they made the fix.
Having said that I do think tat we do need to pony up some cash at 
some stage.. and many others should too

if we want to have something like this. I've said this elsewhere.


Fine. Considering that maintainers already apply patches to the latest 
quarterly branch. If there were to be OS version branches, it would mean 
that maintainers apart from what they are doing now would additionally 
need to apply selected patches to those OS version branches? Considering 
there would be, say, 3 latest version branches, and that 30% of the 
patches that go to the latest branch would need to also be ported to the 
OS version branches, that would roughly mean twice as much work as today?

Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 23/06/2017 12:32, Baho Utot wrote:



On 06/23/17 07:48, RW via freebsd-ports wrote:

On Thu, 22 Jun 2017 22:03:35 -0400
Baho Utot wrote:



The pre-compiled packages is what drove me to build the entire system
as it gave me a broken system that would not work and upon getting it
to function would/**/spontaneous reboot.  My hand built packages
stopped that.

I have built run LFS for 10 years.  I created a packaging system
using rpm for LFS ( it is on github ) .  I worked for turbolinux as a
beta tester and worked with the folks that kept KDE3 alive, so I am
some one that knows something.


And yet you do seem quite exceptionally accident prone.


Oh gee more insults,  is that all you have?

I guess that is encourgement for me to help FreeBSD.  NOT.

I see many posts about FreeBSD needing help and new help leaving just 
as fast.  I wonder why when there is no incentive to work with others 
how that works.  Ya name calling helps.


I think you explained well enough what changes/improvements in 
maintaining of the ports tree you would like to see. Can you be more 
precise what help and from whom you would need in order to implement it?

Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 11:47 pm, Grzegorz Junka wrote:


On 23/06/2017 03:58, Julian Elischer wrote:

On 23/6/17 6:36 am, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:

On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net 
wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the 
state where everything works and has no bugs. (and cannot be, 
because upstreams have bugs) Even if it compiles and installs it 
does not mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean 
others are dilettantes.


The usage of the word dilettante can have negative connotations but 
he is in essential facts correct.


I have spent 30 years on BSD systems in industry, and we almost 
NEVER want the latest and greatest (except at project start time).

What we want is:
  A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only 
for at LEAST 2 years, probably 5.

The key here is the *_*critical fixes only*_* part.

We do NOT want:
A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,

then don't upgrade it in that branch.
We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).


(*) From my experience, the best way to cope with openssl is to 
have everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into 
our own source control branch/tree where we will add our own 
changes to fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually 
will not collide with our private changes/fixes.

From that we generate our required packages.
From our perspective, a yearly branch (6 months would be 'ideal' 
but 12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned 
to when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine 
until they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers 
to do an upgrade earlier.


Can't you just create the branch yourself? It's open source. You 
just clone it and can keep it in Github for free. Then you can apply 
security patches to just the applications you need yourself. If it's 
too difficult you can hire people to apply just specific patches. 
With Github pull requests it's deadly easy. I am sure that if you 
asked maintainers to do the patching for a financial incentive they 
would mind doing it.
I actually explained it..  We do not have the people who understand 
all those ports.
if there is a port hat gets a fix, one assumes there is a maintainer 
who at least understands that port a bit.

I would feel more comfortable if they made the fix.
Having said that I do think tat we do need to pony up some cash at 
some stage.. and many others should too

if we want to have something like this. I've said this elsewhere.



Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 
"freebsd-ports-unsubscr...@freebsd.org"




___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 4:38 pm, Vlad K. wrote:

On 2017-06-23 10:26, demelier.da...@gmail.com wrote:


Release branches won't have many maintenance except individual bug
fixes when security advisories are found. No backport, no updates.


Nothing prevents the maintainers from doing exactly that right now. 
But you see, there are two kinds of ports in the tree:


1) ports where upstream maintains a concept of LTS
2) ports that mix bug, security fixes and new features in even 
point.point releases


For some (all?) major production software like Apache, nginx, PHP, 
PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. 
So for serious production servers this should be easy to maintain as 
the upstream is doing that in the first place.


The problem is then with ports of type #2. And there's lots of them.

Gentoo portage can easily maintain "stable" ports because portage 
doesn't have a single Makefile, it has multiple .ebuild files so 
multiple versions are available under ONE port name, and bumping the 
version while keeping previous ones available is literally just a 
matter of making a copy of the latest .ebuild and fixing the version 
in it like we do with PORTVERSION.
This is why I think our Makefile should be split up into two parts. 
One of which has the interface to the rest of the ports and one of 
which specifies what to download and things that are specific to a 
given version.


then hopefully you could update the second without changing the first.
 Harder to do than say, I know, but I have faced htat challenge soo 
often, in fact i have it right now.
I need  a new azure-agent, in a 10.3 world, where I can not update any 
other packages/ports.





On FreeBSD that's impossible and often ports are separated and 
version baked into the port name. Like www/node from the original 
post of this thread.


But again, that's all doable without having to introduce new 
infrastructure. The ports tree as is can be maintained like this and 
quarterly repos would NOT be required. All it's needed is for 
maintainers to keep a stable version and a latest version. There's 
already plenty of ports done like that, otoh postfix and 
postfix-current, nginx and nginx-devel, etc...


Because the BIGGEST problem in maintaining separate "stable" or LTS 
branches is BACKPORTING fixes for ports in the #2 category, ie. 
those that mix new features with fixes, so you have to CHERRY PICK 
only the fix and BACKPORT it to your "stable" branch. And that's 
even more work often introducing NEW bugs.


BTW, the problem of the original post could've been avoided if the 
user only read UPDATING which clearly stated that www/node becomes 7 
and previous node (6) becomes www/node6.  (20161207) entry.







___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 23/06/2017 03:58, Julian Elischer wrote:

On 23/6/17 6:36 am, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.


The usage of the word dilettante can have negative connotations but he 
is in essential facts correct.


I have spent 30 years on BSD systems in industry, and we almost NEVER 
want the latest and greatest (except at project start time).

What we want is:
  A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for 
at LEAST 2 years, probably 5.

The key here is the *_*critical fixes only*_* part.

We do NOT want:
A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,

then don't upgrade it in that branch.
We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).


(*) From my experience, the best way to cope with openssl is to have 
everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into our 
own source control branch/tree where we will add our own changes to 
fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually will 
not collide with our private changes/fixes.

From that we generate our required packages.
From our perspective, a yearly branch (6 months would be 'ideal' but 
12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned to 
when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine until 
they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers to 
do an upgrade earlier.


Can't you just create the branch yourself? It's open source. You just 
clone it and can keep it in Github for free. Then you can apply security 
patches to just the applications you need yourself. If it's too 
difficult you can hire people to apply just specific patches. With 
Github pull requests it's deadly easy. I am sure that if you asked 
maintainers to do the patching for a financial incentive they would mind 
doing it.


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 06/23/17 10:30, Guido Falsi wrote:

On 06/23/17 15:11, Baho Utot wrote:



On 06/23/17 04:53, Guido Falsi wrote:

On 06/23/17 10:26, demelier.da...@gmail.com wrote:

On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:

Would you agree that release branches would be unnecessary if
somehow
you could select the version of node that the ports tree builds via
some
(as yet unspecified) mechanism?


I've also think about that but I'm not sure if it's easier than having
frozen release branches.


I usually stay away from this kind of threads, but I'd like to point
out a very simple concept that has not been expressed.

The ports tree repository is fully open source, available via
subversion from the FreeBSD project and also mirrored on github. There
is absolutely nothing stopping you(and anyone with time, skill and
willingness to help you) from starting your fork from whichever source
and using whatever tool you prefer, creating the branches you're
describing.

If your model works fine I'm quite sure the FreeBSD community and
project will be quite happy to embrace it.

As stated, the FreeBSD project (core, portmgr and committers) perceive
a manpower problem in relation to implementing what you describe. In
this thread it has been stated that such a manpower problem does not
really exist. I cannot think of a better way to show there actually is
no manpower problem than creating a working example of such a workflow
maintained by just a few people with little effort, as you said
repeatedly.

On other hand demanding and/or insisting that others implement your
idea when they clearly disagree with you is not very constructive.

In relation to the suggestion of a stable or release ports branch:

I'd also like a ports branch where things are merged only when really
needed, some kind of "stable" branch. I don't like the release way you
describe, but maybe it could actually work as an option, but I too see
the manpower problem. An actual working proof of concept like I
described above is the only thing that would persuade me I'm wrong
about that.

(I could try to help with such an experiment but I don't know how much
time I could really spare for it)



Ok, since you are taking the lead on this..


Since when "help with" is a synonym of "lead this effort"?



When do we start?

Where shall I post my repository to?


And updates?

Should the start be for the 12.0 branch or should earlier?

I can start on packaging the base system some time August is that ok
with you and will it fit your schedule?


I'm curious to know which paragraph is the sarcasm especially directed
at, if the first or the last, in parenthesis and meant at giving hand if
someone else has a clear plan. I can't see me leading an effort I
clearly stated I don't think has many chances. Maybe I was not perfectly
clear.




I have faith in you... you can do this...when do we start?

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Guido Falsi]

On 06/23/17 10:53, Guido Falsi wrote:
> On 06/23/17 10:26, demelier.da...@gmail.com wrote:
>> On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:
>>> Would you agree that release branches would be unnecessary if
>>> somehow
>>> you could select the version of node that the ports tree builds via
>>> some
>>> (as yet unspecified) mechanism?
>>
>> I've also think about that but I'm not sure if it's easier than having
>> frozen release branches.
> 
> I usually stay away from this kind of threads, but I'd like to point out
> a very simple concept that has not been expressed.
> 
> The ports tree repository is fully open source, available via subversion
> from the FreeBSD project and also mirrored on github. There is
> absolutely nothing stopping you(and anyone with time, skill and
> willingness to help you) from starting your fork from whichever source
> and using whatever tool you prefer, creating the branches you're
> describing.
> 
> If your model works fine I'm quite sure the FreeBSD community and
> project will be quite happy to embrace it.
> 
> As stated, the FreeBSD project (core, portmgr and committers) perceive a
> manpower problem in relation to implementing what you describe. In this
> thread it has been stated that such a manpower problem does not really
> exist. I cannot think of a better way to show there actually is no
> manpower problem than creating a working example of such a workflow
> maintained by just a few people with little effort, as you said repeatedly.
> 
> On other hand demanding and/or insisting that others implement your idea
> when they clearly disagree with you is not very constructive.
> 
> In relation to the suggestion of a stable or release ports branch:
> 
> I'd also like a ports branch where things are merged only when really
> needed, some kind of "stable" branch. I don't like the release way you
> describe, but maybe it could actually work as an option, but I too see
> the manpower problem. An actual working proof of concept like I
> described above is the only thing that would persuade me I'm wrong about
> that.
> 
> (I could try to help with such an experiment but I don't know how much
> time I could really spare for it)
> 

I'll rephrase that to avoid further confusion:

(If such an effort is started with a clear idea and program, which I
don't have on such a project, I can try to participate as manpower to
it, even though I can't dedicate much time to it)

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Guido Falsi]

On 06/23/17 15:11, Baho Utot wrote:
> 
> 
> On 06/23/17 04:53, Guido Falsi wrote:
>> On 06/23/17 10:26, demelier.da...@gmail.com wrote:
>>> On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:
 Would you agree that release branches would be unnecessary if
 somehow
 you could select the version of node that the ports tree builds via
 some
 (as yet unspecified) mechanism?
>>>
>>> I've also think about that but I'm not sure if it's easier than having
>>> frozen release branches.
>>
>> I usually stay away from this kind of threads, but I'd like to point
>> out a very simple concept that has not been expressed.
>>
>> The ports tree repository is fully open source, available via
>> subversion from the FreeBSD project and also mirrored on github. There
>> is absolutely nothing stopping you(and anyone with time, skill and
>> willingness to help you) from starting your fork from whichever source
>> and using whatever tool you prefer, creating the branches you're
>> describing.
>>
>> If your model works fine I'm quite sure the FreeBSD community and
>> project will be quite happy to embrace it.
>>
>> As stated, the FreeBSD project (core, portmgr and committers) perceive
>> a manpower problem in relation to implementing what you describe. In
>> this thread it has been stated that such a manpower problem does not
>> really exist. I cannot think of a better way to show there actually is
>> no manpower problem than creating a working example of such a workflow
>> maintained by just a few people with little effort, as you said
>> repeatedly.
>>
>> On other hand demanding and/or insisting that others implement your
>> idea when they clearly disagree with you is not very constructive.
>>
>> In relation to the suggestion of a stable or release ports branch:
>>
>> I'd also like a ports branch where things are merged only when really
>> needed, some kind of "stable" branch. I don't like the release way you
>> describe, but maybe it could actually work as an option, but I too see
>> the manpower problem. An actual working proof of concept like I
>> described above is the only thing that would persuade me I'm wrong
>> about that.
>>
>> (I could try to help with such an experiment but I don't know how much
>> time I could really spare for it)
>>
> 
> Ok, since you are taking the lead on this..

Since when "help with" is a synonym of "lead this effort"?

> 
> When do we start?
>> Where shall I post my repository to?
> 
> And updates?
> 
> Should the start be for the 12.0 branch or should earlier?
> 
> I can start on packaging the base system some time August is that ok
> with you and will it fit your schedule?

I'm curious to know which paragraph is the sarcasm especially directed
at, if the first or the last, in parenthesis and meant at giving hand if
someone else has a clear plan. I can't see me leading an effort I
clearly stated I don't think has many chances. Maybe I was not perfectly
clear.

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Fri, Jun 23, 2017 at 01:09:26AM -0500, Mark Linimon wrote:
> I'll go back to what I was doing before

This was an unkind comment and I should not have made it.  My
apologies to all.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 06/23/17 04:53, Guido Falsi wrote:

On 06/23/17 10:26, demelier.da...@gmail.com wrote:

On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:

Would you agree that release branches would be unnecessary if
somehow
you could select the version of node that the ports tree builds via
some
(as yet unspecified) mechanism?


I've also think about that but I'm not sure if it's easier than having
frozen release branches.


I usually stay away from this kind of threads, but I'd like to point out 
a very simple concept that has not been expressed.


The ports tree repository is fully open source, available via subversion 
from the FreeBSD project and also mirrored on github. There is 
absolutely nothing stopping you(and anyone with time, skill and 
willingness to help you) from starting your fork from whichever source 
and using whatever tool you prefer, creating the branches you're 
describing.


If your model works fine I'm quite sure the FreeBSD community and 
project will be quite happy to embrace it.


As stated, the FreeBSD project (core, portmgr and committers) perceive a 
manpower problem in relation to implementing what you describe. In this 
thread it has been stated that such a manpower problem does not really 
exist. I cannot think of a better way to show there actually is no 
manpower problem than creating a working example of such a workflow 
maintained by just a few people with little effort, as you said repeatedly.


On other hand demanding and/or insisting that others implement your idea 
when they clearly disagree with you is not very constructive.


In relation to the suggestion of a stable or release ports branch:

I'd also like a ports branch where things are merged only when really 
needed, some kind of "stable" branch. I don't like the release way you 
describe, but maybe it could actually work as an option, but I too see 
the manpower problem. An actual working proof of concept like I 
described above is the only thing that would persuade me I'm wrong about 
that.


(I could try to help with such an experiment but I don't know how much 
time I could really spare for it)




Ok, since you are taking the lead on this..

When do we start?

Where shall I post my repository to?

And updates?

Should the start be for the 12.0 branch or should earlier?

I can start on packaging the base system some time August is that ok 
with you and will it fit your schedule?









___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matt Smith]

On Jun 23 08:02, scratch65...@att.net wrote:

On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:


scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state
where everything works and has no bugs. (and cannot be, because
upstreams have bugs) Even if it compiles and installs it does not mean
that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others
are dilettantes.


How often have you bought all new versions of the software you
use, Miroslav, even though the versions you replaced still worked
fine?  I'd bet that you've never done that, and never will:
you're an adult, and have more important uses for your time and
money.

How often do you look around your flat or house for something to
"fix" even though everthing works well enough?  I'd bet not
often, if ever -- you probably always have so much real work to
do that you worry you'll never get it all done if you live to be
120.

There are individuals who claim to "need" the latest Mercedes or
Ferrari, or a bigger yacht, or a chalet in Switzerland.  But that
kind of "need" isn't on the same level as someone's need for a
place to live, or a way to get to work, or medical care for their
kids.

Similarly, few people constantly "need" the latest software. Even
if the new release has a feature that will make their work
easier, the release after that one is not likely to have
*another* such feature.   Nearly all adults can do their
computer-based work just fine without ever having the
Latest-And-Greatest hardware and software.  Those who claim they
simply *must* always have bleeding-edge kit are kidding someone.
Or delusional.
___


Can we stop suggesting that everybody in the world wants a stable 
release that doesn't frequently change, or that people who want to use 
the latest versions of software are delusional please?


I use FreeBSD *precisely* because it mostly keeps up with the latest 
stable versions of things. I have postfix 3.2, pgsql 9.6, nginx 1.13, 
libressl 2.5 etc. It's usually impossible to do this with linux unless 
you install things directly from source.


I upgrade my ports/packages via poudriere every single day which mostly 
just takes 2 minutes of my time as usually that results in maybe one or 
two packages being updated at a time. I see this as a positive thing 
rather than doing one massive huge upgrade every 3 months.


If I see that a package is going to have a major version upgrade then I 
say no and cancel the update until I have a spare half hour or so later 
in the day. Then I will spend the time seeing what the differences are 
and changing my config etc as appropriate.


I actually like this way of working and it suits me fine. I enjoy 
learning the ins and outs of new software. If everybody had the attitude 
of never spending time doing major version updates then we would all be 
in the python3 verses python 2 situation where virtually nobody is 
writing python3 code.


I'm not going to argue against what you guys are asking for, each to 
their own, you have your own requirements and that's fair enough. But I 
just wanted to make a point that the way that FreeBSD currently does it 
is not "nobody wants it done this way". At least one person does thanks.



--
Matt
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 06/23/17 07:48, RW via freebsd-ports wrote:

On Thu, 22 Jun 2017 22:03:35 -0400
Baho Utot wrote:



The pre-compiled packages is what drove me to build the entire system
as it gave me a broken system that would not work and upon getting it
to function would/**/spontaneous reboot.  My hand built packages
stopped that.

I have built run LFS for 10 years.  I created a packaging system
using rpm for LFS ( it is on github ) .  I worked for turbolinux as a
beta tester and worked with the folks that kept KDE3 alive, so I am
some one that knows something.


And yet you do seem quite exceptionally accident prone.


Oh gee more insults,  is that all you have?

I guess that is encourgement for me to help FreeBSD.  NOT.

I see many posts about FreeBSD needing help and new help leaving just as 
fast.  I wonder why when there is no incentive to work with others how 
that works.  Ya name calling helps.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

On Fri, 23 Jun 2017 00:36:19 +0200, Miroslav Lachman
<000.f...@quip.cz> wrote:

>scratch65...@att.net wrote on 2017/06/23 00:15:
>> [Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
>>  wrote:
>>
>>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
 My problem is that my industry experience tells me that reducing
 the frequency of port releases is practically *guaranteed* to be
 a Really Good Thing for everyone.
>>>
>>> I remember before we had the quarterly releases, and people on the
>>> mailing lists complained constantly about the ports bits only being
>>> available once per release, or rolling with -head.
>>
>> Mark, I can only suppose that those complainers are dilettantes
>> of some sort who believe that having The Latest-And-Greatest Bits
>> is a social-status enhancer.  **Nobody** with real work to do
>> ever willingly fools away time "fixing" what isn't broken.
>
>And this is where you are so wrong. Ports tree is never in the state 
>where everything works and has no bugs. (and cannot be, because 
>upstreams have bugs) Even if it compiles and installs it does not mean 
>that it is not broken and nobody needs newer version.
>Just because your needs are different than others doesn't mean others 
>are dilettantes.

How often have you bought all new versions of the software you
use, Miroslav, even though the versions you replaced still worked
fine?  I'd bet that you've never done that, and never will:
you're an adult, and have more important uses for your time and
money.   

How often do you look around your flat or house for something to
"fix" even though everthing works well enough?  I'd bet not
often, if ever -- you probably always have so much real work to
do that you worry you'll never get it all done if you live to be
120.

There are individuals who claim to "need" the latest Mercedes or
Ferrari, or a bigger yacht, or a chalet in Switzerland.  But that
kind of "need" isn't on the same level as someone's need for a
place to live, or a way to get to work, or medical care for their
kids.

Similarly, few people constantly "need" the latest software. Even
if the new release has a feature that will make their work
easier, the release after that one is not likely to have
*another* such feature.   Nearly all adults can do their
computer-based work just fine without ever having the
Latest-And-Greatest hardware and software.  Those who claim they
simply *must* always have bleeding-edge kit are kidding someone.
Or delusional.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Vlad K.]

On 2017-06-23 11:35, demelier.da...@gmail.com wrote:


Release branches do not need backports.


I think we have different concepts of "backport" here. I'm not talking 
about backports as defined by debian backports repository. I'm talking 
about taking a piece of code from NEWER version and turning it into a 
patch for OLDER version.


Unless you mean that release branches would get no fixes, period? 
That's well, "svn checkout" and don't touch it ever again :)




That's the only way to deal with security/bug fixes for ports that mix 
new features (that may break things) with fixes, when they release a new 
version.


Either that, or you simply bump the version and get both the fixes AND 
new features but that's what's being done with QUARTERLY now, and 
we're back to square one.




--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Fri, 2017-06-23 at 10:38 +0200, Vlad K. wrote:
> But again, that's all doable without having to introduce new 
> infrastructure. The ports tree as is can be maintained like this and 
> quarterly repos would NOT be required. All it's needed is for 
> maintainers to keep a stable version and a latest version. There's 
> already plenty of ports done like that, otoh postfix and 
> postfix-current, nginx and nginx-devel, etc...

Yes but again if not all ports follow this system, we still have the
problem of having potential major upgrades.

> Because the BIGGEST problem in maintaining separate "stable" or LTS 
> branches is BACKPORTING fixes for ports in the #2 category, ie.
> those 
> that mix new features with fixes, so you have to CHERRY PICK only
> the 
> fix and BACKPORT it to your "stable" branch. And that's even more
> work 
> often introducing NEW bugs.

Release branches do not need backports.

> BTW, the problem of the original post could've been avoided if the
> user 
> only read UPDATING which clearly stated that www/node becomes 7 and 
> previous node (6) becomes www/node6.  (20161207) entry.

Completely off topic, if you upgrade the ports tree, you should update
all your packages as doing partial upgrades is even worse (shared
library rebuilds for instance).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matthew Seaman]

On 06/23/17 09:47, demelier.da...@gmail.com wrote:
> On Thu, 2017-06-22 at 16:11 -0500, Mark Linimon wrote:
>> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
>>> My problem is that my industry experience tells me that reducing
>>> the frequency of port releases is practically *guaranteed* to be
>>> a Really Good Thing for everyone.
>>
>> I remember before we had the quarterly releases, and people on the
>> mailing lists complained constantly about the ports bits only being
>> available once per release, or rolling with -head.
>>
> 
> Quarterly branches do not solve anything.
> 
> A user installs a machine on March, it uses 2017Q1. Then in April an
> additional software must be installed, as we are in April, 2017Q2 is
> available so two choices:
> 
> a. the user keeps 2017Q1 but won't have any security fixes as it is not
> maintained anymore; possibly having security flaws.
> 
> b. the user switches to 2017Q2, this tree will probably have major
> upgrades and possibly breaking existing stuff.
> 
> To me, quarterly branches are completely useless as they are not
> maintained enough in time. Replacing them with release branches would
> solve everything explained in this thread.

Just responding to a message in this thread at random, and not
specifically directed at the person whose message I'm replying to.

This thread is exactly the sort of sterile argument that the brand new
FCP process was invented to handle.

https://github.com/freebsd/fcp

Read the fcp-.md document for details on how the process works.

If sufficient people really do want to change the way the ports are
branched, then write a proposal.  You're going to need to think about it
carefully, and consider the needs of all ports users, not just your own
specific case.  Plus it will need to be achievable with the resources
available.

If you can get enough people behind your proposal to swing a vote by
core, then changes will happen.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Guido Falsi]

On 06/23/17 10:26, demelier.da...@gmail.com wrote:

On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:

Would you agree that release branches would be unnecessary if
somehow
you could select the version of node that the ports tree builds via
some
(as yet unspecified) mechanism?


I've also think about that but I'm not sure if it's easier than having
frozen release branches.


I usually stay away from this kind of threads, but I'd like to point out 
a very simple concept that has not been expressed.


The ports tree repository is fully open source, available via subversion 
from the FreeBSD project and also mirrored on github. There is 
absolutely nothing stopping you(and anyone with time, skill and 
willingness to help you) from starting your fork from whichever source 
and using whatever tool you prefer, creating the branches you're describing.


If your model works fine I'm quite sure the FreeBSD community and 
project will be quite happy to embrace it.


As stated, the FreeBSD project (core, portmgr and committers) perceive a 
manpower problem in relation to implementing what you describe. In this 
thread it has been stated that such a manpower problem does not really 
exist. I cannot think of a better way to show there actually is no 
manpower problem than creating a working example of such a workflow 
maintained by just a few people with little effort, as you said repeatedly.


On other hand demanding and/or insisting that others implement your idea 
when they clearly disagree with you is not very constructive.


In relation to the suggestion of a stable or release ports branch:

I'd also like a ports branch where things are merged only when really 
needed, some kind of "stable" branch. I don't like the release way you 
describe, but maybe it could actually work as an option, but I too see 
the manpower problem. An actual working proof of concept like I 
described above is the only thing that would persuade me I'm wrong about 
that.


(I could try to help with such an experiment but I don't know how much 
time I could really spare for it)


--
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Thu, 2017-06-22 at 16:11 -0500, Mark Linimon wrote:
> On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
> > My problem is that my industry experience tells me that reducing
> > the frequency of port releases is practically *guaranteed* to be
> > a Really Good Thing for everyone.
> 
> I remember before we had the quarterly releases, and people on the
> mailing lists complained constantly about the ports bits only being
> available once per release, or rolling with -head.
> 

Quarterly branches do not solve anything.

A user installs a machine on March, it uses 2017Q1. Then in April an
additional software must be installed, as we are in April, 2017Q2 is
available so two choices:

a. the user keeps 2017Q1 but won't have any security fixes as it is not
maintained anymore; possibly having security flaws.

b. the user switches to 2017Q2, this tree will probably have major
upgrades and possibly breaking existing stuff.

To me, quarterly branches are completely useless as they are not
maintained enough in time. Replacing them with release branches would
solve everything explained in this thread.

Regards,

-- 
David Demelier



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Vlad K.]

On 2017-06-23 10:26, demelier.da...@gmail.com wrote:


Release branches won't have many maintenance except individual bug
fixes when security advisories are found. No backport, no updates.


Nothing prevents the maintainers from doing exactly that right now. But 
you see, there are two kinds of ports in the tree:


1) ports where upstream maintains a concept of LTS
2) ports that mix bug, security fixes and new features in even 
point.point releases


For some (all?) major production software like Apache, nginx, PHP, 
PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies. So 
for serious production servers this should be easy to maintain as the 
upstream is doing that in the first place.


The problem is then with ports of type #2. And there's lots of them.

Gentoo portage can easily maintain "stable" ports because portage 
doesn't have a single Makefile, it has multiple .ebuild files so 
multiple versions are available under ONE port name, and bumping the 
version while keeping previous ones available is literally just a matter 
of making a copy of the latest .ebuild and fixing the version in it like 
we do with PORTVERSION.


On FreeBSD that's impossible and often ports are separated and version 
baked into the port name. Like www/node from the original post of this 
thread.


But again, that's all doable without having to introduce new 
infrastructure. The ports tree as is can be maintained like this and 
quarterly repos would NOT be required. All it's needed is for 
maintainers to keep a stable version and a latest version. There's 
already plenty of ports done like that, otoh postfix and 
postfix-current, nginx and nginx-devel, etc...


Because the BIGGEST problem in maintaining separate "stable" or LTS 
branches is BACKPORTING fixes for ports in the #2 category, ie. those 
that mix new features with fixes, so you have to CHERRY PICK only the 
fix and BACKPORT it to your "stable" branch. And that's even more work 
often introducing NEW bugs.


BTW, the problem of the original post could've been avoided if the user 
only read UPDATING which clearly stated that www/node becomes 7 and 
previous node (6) becomes www/node6.  (20161207) entry.





--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Fri, 2017-06-23 at 00:31 +, Grzegorz Junka wrote:
> A user would probably start with precompiled packages. Only power
> users 
> who know what they are doing would try to compile the packages 
> themselves, and at that point I would expect them to know a thing or
> two 
> about verifying that they compile and work fine.

Precompiled packages are updated as well nowadays.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Thu, 2017-06-22 at 11:57 -0700, Dave Hayes wrote:
> Would you agree that release branches would be unnecessary if
> somehow 
> you could select the version of node that the ports tree builds via
> some 
> (as yet unspecified) mechanism?

I've also think about that but I'm not sure if it's easier than having
frozen release branches.

Release branches won't have many maintenance except individual bug
fixes when security advisories are found. No backport, no updates.

On the other hand, having to deal case-by-case for which ports should
have version is very hard and complex. It's the case of some of them,
node, postgresql, apache. But then we will have thousands of ports to
add just to provides different versions.

Cheers,

-- 
David Demelier
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

You didn't read (or ignored) the last half of my post.

Whatever.

I'll go back to what I was doing before, e.g., cleaning up other people's
messes.  Your first two guesses of "what type of commit bits made the
messes" don't count.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Fri, Jun 23, 2017 at 01:36:26PM +0800, Julian Elischer wrote:
> The problem is that such a set of sponsored branches does not exist so
> knowing who'd sign up and who would't is just guesswork

And that's why neither myself or the other people who have in the past
considered such a business have gone into it.

I rejected it as "a fantastic way to work hard and lose tons of money".
I've had enough of those in my career, thanks.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 1:23 pm, Kurt Jaeger wrote:

Hi!


There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.
http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

That is ONE kind of installation.

Well, there's the thinking that in the not-to-far future, everything
is connected, and you'll need to be able to update at any time
because of whatever security/threat that IT ecosystem throws at you.


It DOES NOT WORK when th most you can upgrade a customer system is
once a year or once every two years.

The 'other side' of the debate thinks: Well, if they think this
is the way to do it, they have a problem and need to change
their procedures.

The viewpoint is: That system can start debating with the next
worm/trojan coming along, but that won't help. The assumption
is: everything is connected/on the internet, and not even
voluntarily.

Think connected cars, IoT etc.


I will add that such users would help their own case by fixing such
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of
"corporate sponsors" for these branches.

Given the state of fundraising in open source, I doubt that this
will be viable.

My personal experience is that if it were put in the form of an annual s
subscription, most mid sized corporate finance offices wouldn't blink 
at $20k
if they thought it was an important part of their product.  (that's 
the key)

Some wouldn't blink at 50K.  ("the software is free but we need to
help pay for people to do real work to keep it safe, it'll save us (some
fraction of) a full time person").

The problem is that such a set of sponsored branches does not exist so
knowing who'd sign up and who would't is just guesswork, and the companies
have made "alternative arrangements"  whether that means somewhat forgoing
the ports tree (e.g Vicor) or building an infrastructure around ports
head ( e.g. Panzura), or having some other snapshotting system ( e.g 
Ironport/Cisco)



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Kurt Jaeger]

Hi!

> > There's a blog post from one of the folks that explains the
> > idea behind that 'fast update' mode of operations, and yes,
> > he's doing real work.

> > http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

> That is ONE kind of installation.

Well, there's the thinking that in the not-to-far future, everything
is connected, and you'll need to be able to update at any time
because of whatever security/threat that IT ecosystem throws at you.

> It DOES NOT WORK when th most you can upgrade a customer system is 
> once a year or once every two years.

The 'other side' of the debate thinks: Well, if they think this
is the way to do it, they have a problem and need to change
their procedures.

The viewpoint is: That system can start debating with the next
worm/trojan coming along, but that won't help. The assumption
is: everything is connected/on the internet, and not even
voluntarily.

Think connected cars, IoT etc.

> I will add that such users would help their own case by fixing such 
> issues and feeding the changes back to their branches upstream,
> thus helping maintain the branch. Maybe we could have a system of 
> "corporate sponsors" for these branches.

Given the state of fundraising in open source, I doubt that this
will be viable.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 12:39 pm, Mark Linimon wrote:

On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote:

What we want is:
A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for
at LEAST 2 years, probably 5.
The key here is the *_*critical fixes only*_* part.

And how much is that worth to you and/or your company?

glad you asked.

If we had such a setup it would probably be worth a good part of a 
person's salary.


Since we have had to do without it, we have workarounds in place that 
took a lot of work to make.
But we are now running a  parallel system where we are taking 
snapshots of head and using them.
The downside is that we don't have the resources to follow all the 
Security issues so we are forced
to do cross-revision upgrades sometimes where for example all the 
packages we install were
compiled from a tree that approximates 10.3 ports, but the openssl 
package is from a source tree
that is much newer.  We enjoy this about as much as having our 
corporate wisdom teeth pulled out

but it's forced on us.
In the near future we will be taking a new snapshot for the next 
release. What branch and revision
of the ports tree wil be snapshotted is still not decided, If there 
were a suitable first-half-2017
stable branch we'd take that for sure, then we'd follow it, merging 
changes in, and probably feeding

fixes back.

Since there are no "security patch only" branches, What we will 
probably end up doing is
snapshotting head and crossing our fingers hoping that we notice any 
relevant
vulnerabilities and have the time to work out a fix. Of course If 
there is no easy patch, we
may have to do single-package upgrades, which is usually only painless 
for  a short time

after the snapshot, because the Makefile infrastructure keeps changing.



I mean, honestly.  You constantly criticize the volunteers for not doing
what you need.  Well _need_, to me, implies the existence of some kind
of incentive.  I can state to you, flatly, that "a feeling of a job well
done" isn't _sufficient incentive_ to do professional-level QA.  There's
a reason people get _paid to do it_: it's hard, long, tedious, unrewarding
work, and it never ends.

Clearly, relying on _volunteers_ to do professional-level QA isn't working
out for you.

Thus, IMVVHO, at this point, to get what you _need_, you need to get out
your checkbook and provide a _financial_ incentive.  In my experience,
with the volunteers that we have, we can barely keep things afloat as
it is.  It's sufficiently hard to recruit people, and burnout is high
-- especially given the grief we take.

(I won't even start on how even "critical fixes" can drag in the need
to update dependencies, which then conflict with each other, and so on
and so forth, and thus even "critical fixes" aren't trivial.)

Summary: you are providing negative incentive to the ports crew, with
no upside for them, and you can't understand why it doesn't work.

tl;dr: you want us to be RedHat but with no paid employees.

mcl



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Fri, Jun 23, 2017 at 11:58:14AM +0800, Julian Elischer wrote:
> What we want is:
> A "recent" starting point for our next project/upgrade to start from
> and an ongoing version of that, which will get critical fixes only for
> at LEAST 2 years, probably 5.
> The key here is the *_*critical fixes only*_* part.

And how much is that worth to you and/or your company?

I mean, honestly.  You constantly criticize the volunteers for not doing
what you need.  Well _need_, to me, implies the existence of some kind
of incentive.  I can state to you, flatly, that "a feeling of a job well
done" isn't _sufficient incentive_ to do professional-level QA.  There's
a reason people get _paid to do it_: it's hard, long, tedious, unrewarding
work, and it never ends.

Clearly, relying on _volunteers_ to do professional-level QA isn't working
out for you.

Thus, IMVVHO, at this point, to get what you _need_, you need to get out
your checkbook and provide a _financial_ incentive.  In my experience,
with the volunteers that we have, we can barely keep things afloat as
it is.  It's sufficiently hard to recruit people, and burnout is high
-- especially given the grief we take.

(I won't even start on how even "critical fixes" can drag in the need
to update dependencies, which then conflict with each other, and so on
and so forth, and thus even "critical fixes" aren't trivial.)

Summary: you are providing negative incentive to the ports crew, with
no upside for them, and you can't understand why it doesn't work.

tl;dr: you want us to be RedHat but with no paid employees.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 7:28 am, Grzegorz Junka wrote:


On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not 
exert

much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example.


here lies the crux of the problem.
FreeBSD is often not a front-end software module.
It is often used to provision off-line (from a 
management/administrative perspective) systems.

Front end or personal systems can be upgraded day by day.
Real products such as routers, proxies, gateways, accounting systems, 
firewalls etc. can NOT be upgraded every day.

you are lucky if the customer allows you to do it once a year.

Chrome is releasing a new version every couple of days. Sure, I 
don't upgrade every release, but when I am developing a website, I 
want to test using the same version that my customers are using, 
which is the latest, since Chrome on Windows updates itself 
automatically. The same with new versions of Firefox. Often new 
versions of browsers require new versions of libraries to support 
new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated 
version of node or npm.


Take server-side development as another example. Erlang is releasing 
a new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library 
that you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely 
come a time when you will need to upgrade. And for every user that 
time will be different. The current model is in my opinion the most 
common denominator - we can't maintain multiple branches with past 
versions so lets try to properly maintain one with current versions.


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 
"freebsd-ports-unsubscr...@freebsd.org"





___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 2:57 am, Dave Hayes wrote:

On 06/22/2017 11:43, demelier.da...@gmail.com wrote:

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore.


I completely agree that an annoying consequence of what the 
volunteers are doing with the ports tree. These unwelcome surprises 
are the bulk of my non-automated work in creating package repositories.


Frankly, I also wish this kind of thing would stop. Ultimately my 
wishes are irrelevant for reasons far far beyond the scope of this 
thread.



Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.


That sounds reasonable...yet others will likely expect www/node to 
always be the latest version. Perhaps these others might complain 
that it is not the latest version and it would be reasonable to have 
node always be at the latest version.
then at install they should set their packages to follow head, and 
ignore the branches.


Would you agree that release branches would be unnecessary if 
somehow you could select the version of node that the ports tree 
builds via some (as yet unspecified) mechanism?



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 23/6/17 10:39 am, Kurt Jaeger wrote:

Hi!


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.

There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.

http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/


That is ONE kind of installation.

It only works if you are talking about a software module that is 
either dynamically delivered (think web apps that are downloaded every 
time they are run) or at lear often redelivered. (say, a personal 
system that gets automatic upgrades, a-la slack on OS-X (they seem to 
have  anew version every week or two)
It DOES NOT WORK when th most you can upgrade a customer system is 
once a year or once every two years.


That kind of installation basically "follows head". It doesn't need 
ANY branches. So quarterly branches are of no use to them either.
They are a minority of all commercial users, and a completely non 
existent part of appliance manufacturers,

(because you can't do it that way unless you only have 2 customers (*)).

 * and even then, the customers may only allow you to upgrade every 
so often. For example Bank of America only allow their FreeBSD 
machines to be upgraded after a several month testing and burn-in 
period on a parallel test system with real data and dummy users, and 
that can obviously only happen on a yearly scale as it costs a lot to 
do. (ask Devin about the details..it's been a while since I worked on 
their stuff but I know it's still similar).


To be useful any branch must:
1/ not make unneeded changes, but DO include all/most CRITICAL changes.
2/ stay around and be buildable for at least 3 years, preferably 5.

Note that a company can take care of point 2 themselves to some extent 
by mirroring etc.
but they probably don't have the expertise to handle all if the 
critical (security) patches part of the picture.


I will add that such users would help their own case by fixing such 
issues and feeding the changes back to their branches upstream,
thus helping maintain the branch. Maybe we could have a system of 
"corporate sponsors" for these branches.





___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Kurt Jaeger]

Hi!

> Mark, I can only suppose that those complainers are dilettantes
> of some sort who believe that having The Latest-And-Greatest Bits
> is a social-status enhancer.  **Nobody** with real work to do
> ever willingly fools away time "fixing" what isn't broken.

There's a blog post from one of the folks that explains the
idea behind that 'fast update' mode of operations, and yes,
he's doing real work.

http://blog.koehntopp.info/index.php/1776-rolling-out-patches-and-changes-often-and-fast/

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 8:31 PM, Grzegorz Junka wrote:


On 22/06/2017 23:16, Baho Utot wrote:

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean 
others are dilettantes.




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). 
Then builds the base from releng-11.0.  Followed by building the 
ports I need.  That doesn't give me a usable system always. Should I 
not be able to do the above and expect a stable system? If not I am 
running the wrong OS/system.  Updates are another monster as I do not 
want to place my now running system ( finally stable ) and do this 
all over again.  I am not up for that.  Hell FreeBSD can not even 
boot my dual boot system Win7 and FreeBSD 11.0 on zfs raid without 
going to BIOS and selecting the disk to boot from.  No one here could 
point me to how to set it up using grub as a boot loader!  The only 
information I got was to wing it using half baked information.


A user would probably start with precompiled packages. Only power 
users who know what they are doing would try to compile the packages 
themselves, and at that point I would expect them to know a thing or 
two about verifying that they compile and work fine.

Grzegorz


The pre-compiled packages is what drove me to build the entire system as 
it gave me a broken system that would not work and upon getting it to 
function would/**/spontaneous reboot.  My hand built packages stopped that.


I have built run LFS for 10 years.  I created a packaging system using 
rpm for LFS ( it is on github ) .  I worked for turbolinux as a beta 
tester and worked with the folks that kept KDE3 alive, so I am some one 
that knows something.


I can say from a user stand point ( and previous packager ) that the 
base packages is nothing but a f'n mess.  I still have not cleaned up my 
desktop system after trying base packages.  I was told the only way to 
fix that was to delete the entire pkg database and reinstall all the 
packages I had installed.   That is just not acceptable.  One should be 
able to just delete the entry of the package in the package database and 
move on.  I was going to build a tool to do just that.  I then came 
across OpenBSD, so I have delayed that until I decide if OpenBSD is a 
good fit for me. pkgng is almost a beta product at this date.


What is wrong with open source projects is this holier that thou 
attitude,  you folks would do well to lose that attitude and start 
working WITH instead of against the users of your system.   They may not 
always be right but they SHOULD BE AT LEAST HEARD.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 23:16, Baho Utot wrote:

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). 
Then builds the base from releng-11.0.  Followed by building the ports 
I need.  That doesn't give me a usable system always. Should I not be 
able to do the above and expect a stable system? If not I am running 
the wrong OS/system.  Updates are another monster as I do not want to 
place my now running system ( finally stable ) and do this all over 
again.  I am not up for that.  Hell FreeBSD can not even boot my dual 
boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS 
and selecting the disk to boot from.  No one here could point me to 
how to set it up using grub as a boot loader!  The only information I 
got was to wing it using half baked information.


A user would probably start with precompiled packages. Only power users 
who know what they are doing would try to compile the packages 
themselves, and at that point I would expect them to know a thing or two 
about verifying that they compile and work fine.

Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example. Chrome is releasing a new version 
every couple of days. Sure, I don't upgrade every release, but when I am 
developing a website, I want to test using the same version that my 
customers are using, which is the latest, since Chrome on Windows 
updates itself automatically. The same with new versions of Firefox. 
Often new versions of browsers require new versions of libraries to 
support new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated version 
of node or npm.


Take server-side development as another example. Erlang is releasing a 
new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library that 
you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely come 
a time when you will need to upgrade. And for every user that time will 
be different. The current model is in my opinion the most common 
denominator - we can't maintain multiple branches with past versions so 
lets try to properly maintain one with current versions.


Grzegorz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not mean 
that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). Then 
builds the base from releng-11.0.  Followed by building the ports I 
need.  That doesn't give me a usable system always.  Should I not be 
able to do the above and expect a stable system?  If not I am running 
the wrong OS/system.  Updates are another monster as I do not want to 
place my now running system ( finally stable ) and do this all over 
again.  I am not up for that.  Hell FreeBSD can not even boot my dual 
boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS and 
selecting the disk to boot from.  No one here could point me to how to 
set it up using grub as a boot loader!  The only information I got was 
to wing it using half baked information.


FreeBSD needs a stable OS followed by a booting method/software followed 
by a stable ports system.


Linux became the custer it has because of the constant change for 
changes sake.  FreeBSD is close behind.
That is why I am going to switch to Open BSD as it has "correctness in 
mind" rather than "I got to have the lastest even if it gets me nothing" 
mindset.


You folks are beating yourself to death trying to keep up when it just 
is not necessary ( for most cases, although some one will say that they 
need the latest version of package XYZ ).  For instance, what do I gain 
by using version 11.0 and the ports head, over version 10.0 and the 
ports head at that time?   Well nothing.  YMMV.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Miroslav Lachman]

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not mean 
that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:

>On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
>> My problem is that my industry experience tells me that reducing
>> the frequency of port releases is practically *guaranteed* to be
>> a Really Good Thing for everyone.
>
>I remember before we had the quarterly releases, and people on the
>mailing lists complained constantly about the ports bits only being
>available once per release, or rolling with -head.

Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken. That's
why there are still millions of XP boxes in daily use despite
everything M$ has been able to do to force people to give them
up.

's mise le meas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Mark Linimon]

On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:
> My problem is that my industry experience tells me that reducing
> the frequency of port releases is practically *guaranteed* to be
> a Really Good Thing for everyone.

I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.

In other words, the exact opposite of what you are suggesting.

tl;dr: there is no way to satisfy everyone.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 11:43, demelier.da...@gmail.com wrote:

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore.


I completely agree that an annoying consequence of what the volunteers 
are doing with the ports tree. These unwelcome surprises are the bulk of 
my non-automated work in creating package repositories.


Frankly, I also wish this kind of thing would stop. Ultimately my wishes 
are irrelevant for reasons far far beyond the scope of this thread.



Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.


That sounds reasonable...yet others will likely expect www/node to 
always be the latest version. Perhaps these others might complain that 
it is not the latest version and it would be reasonable to have node 
always be at the latest version.


Would you agree that release branches would be unnecessary if somehow 
you could select the version of node that the ports tree builds via some 
(as yet unspecified) mechanism?

--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

If you want to get rid of somebody, just tell them something
for their own good.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[demelier . david]

On Thu, 2017-06-22 at 10:43 -0700, Dave Hayes wrote:
> They are not useless to me.
> 
> I maintain a fair number of different package repositories for
> various 
> purposes. Over a long period of time I've found that trying to build 
> from HEAD is a random crapshoot as to whether everything you want
> will 
> build without you having to svn random ports back and forth through
> the 
> revision tree (or patch them yourself), patch your build processes, 
> and/or ask for help (which you often might not get).
> 
> In contrast, the quarterly branches (so far) have built everything
> I've 
> wanted cleanly and this has been true for some years. No, the 
> quarterlies are not perfect, but they seem to be closer to perfect
> than 
> HEAD is.
> 

The problem is not if a port will build fine or not.

Let me use my example of www/node back. I have built the port www/node
in poudriere using this origin (so no version). At the time I've built
it it was a 6.x version. When I upgraded my machine, www/node has
switched to 7.x version and since this software follows semantic
versioning, every application using the 6.x branch may or may not work
anymore. And that was my case, etherpad could not start. Fortunately, I
had the chance that the port www/node6 existed and I could downgrade.

Some people would argue to upgrade etherpad to a version that supports
node 7.x but that is not always an option. Hint: how many application
are still not python 3 compatible ? :-)

Now, I'm in a state where if I pull the ports tree, I must check if
www/node6 still exists or I must not upgrade.

With releases branches I will be sure that:

  1. www/node will *always* be at a 6.x version;
  2. www/node will still be supported for the version of the FreeBSD
system.

Regards,

-- 
David Demelier
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 09:16, scratch65...@att.net wrote:

I can't help feeling that there's something very wrong when
people for whom the system is a tool rather than a plaything have
to work around the choices made by the "official" developers.


I'd say this is true no matter what OS you use these days.
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

It is only knowledge that will destroy bias.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Dave Hayes]

On 06/22/2017 08:53, Julian Elischer wrote:

Yeah but the quarterly branches are relatively useless because they a
not sync'd to anything and mean nothing special to anyone.


They are not useless to me.

I maintain a fair number of different package repositories for various 
purposes. Over a long period of time I've found that trying to build 
from HEAD is a random crapshoot as to whether everything you want will 
build without you having to svn random ports back and forth through the 
revision tree (or patch them yourself), patch your build processes, 
and/or ask for help (which you often might not get).


In contrast, the quarterly branches (so far) have built everything I've 
wanted cleanly and this has been true for some years. No, the 
quarterlies are not perfect, but they seem to be closer to perfect than 
HEAD is.


Note that you have to handle the edge cases (recent security patches, 
revision mismatch, etc) anyway, HEAD or no. I find I have to handle less 
with the quarterlies because they do generally build cleanly.

--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
 *The opinions expressed above are entirely my own* 

Possession of a system of knowledge, or an interest in it,
or in discovering one, shouldn't be assumed to confer any
license or capacity to operate it. Individual criticisms of
a system, incapacity to operate it, or dissatisfaction with
it should not be confused with any shortcoming of the system
itself.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 16:16:44 +0200, Baptiste Daroussin
 wrote:

>The model with one branch per release will bring it to way more with a
>maintenance window way larger 

It would indeed!  Factor of 3, I think.  

But I'm really not suggesting that, I'm suggesting that a better
schedule would be one ports release for v10, one for v11, one for
v12, etc.   It could be done for n.0 or any of the others.  Were
it my decision, I'd probably go for n.1, since there might be
fewer bugs than in n.0, but the difference might not be
significant.

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.  Yet apparently you and others
on the dev team don't like the idea, and no matter how I much I
think about it, I haven't been able to understand why you don't.

's mise le meas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Fri, 23 Jun 2017 00:01:45 +0800, Julian Elischer
 wrote:

>I've had this conversation with ports several times, But the requirements
>of  'business' is not their interest.  In fact i was told several times,
>"Don't use our quarterly packages, make your own with poudriere".
>(which makes one wonder "What is the purpose of he quarterlies?)

Indeed.  

I can't help feeling that there's something very wrong when
people for whom the system is a tool rather than a plaything have
to work around the choices made by the "official" developers.
Besides your question, I'd add:  for whom are the developers
developing, if not for those who want a useful tool rather than a
hobby? 

's mise le meas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matthew Seaman]

On 2017/06/22 20:56, Baho Utot wrote:
> One could still use releng 11.0 ports with 10.3 OS could they not

No, not in general.

You've got it the wrong way round.

You might get away with releng 10.3 ports and 11.0 OS for a while but it
will likely cause you grief when you do run afoul of a necessary
security update and try and update stuff.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 17:30:10 +0200, Torsten Zuehlsdorff
 wrote:

>I regularly seeing admins setting up different Ubuntu versions, because 
>at one you have PHP 7 and on the other MySQL 5.7, but not both at the 
>same Ubuntu version.

Which is one of the nice things about having central development
rather than a dozen forks being developed separately.  But it
still doesn't work perfectly, since we also have some skews like
that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 11:50 pm, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)



  2) Even if we could scrape up enough people to support however many
branches you are proposing, remember they are all volunteers.  It's hard
enough getting people to maintain the existing quarterly branches as it
is, and those are relatively short lived so that most merges from head
are pretty trivial.  People really aren't going to want to do
essentially repetitive merges to branches where everything else is up to
X years older than head.  Which would make it both tedious and
frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2


I've had this conversation with ports several times, But the requirements
of  'business' is not their interest.  In fact i was told several times,
"Don't use our quarterly packages, make your own with poudriere".
(which makes one wonder "What is the purpose of he quarterlies?)

My suggestion is to ignore the existence of the quarterly snapshots as
they are neither stable (they change every 3 months out from under 
you) nor snapshots,
(they a re updated randomly a bit at a time. This just doesn't work 
for what business needs.
So the only alternative is to have a SVN mirror, and take your own 
snapshots, and keep your eye

on the security notices.



Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that?

's mise le meas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"




___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 22.06.2017 21:56, Baho Utot wrote:



On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote:

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to 
handle the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy 
to maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the 
upgrade path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - 
they just hurt you daily. :D


No not really I ran LFS servers and desktops for 10 years


This does not mean that you're hit by the bugs i am. The most recent 
example is a bug in curl parsing a #. This was introduced via a security 
fix in Ubuntu and make use of '#' in passwords for htaccess impossible, 
until you use new curl releases. Which are not available on Ubuntu 16 
LTS for some more years.


Having a "releng ports" version that goes with a releng version of 
the OS would be great by me.   Linux from scratch does this and it 
works very well. 


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, 
because at one you have PHP 7 and on the other MySQL 5.7, but not both 
at the same Ubuntu version.


BSD != Linux so your comparison is invalid.


No, that is the point of my comparison. Luckily BSD != Linux and also 
the various distributions schemes of updates having there up- and downsides.
But in such discussions its often that only the own use-case is 
mentioned. And i want to widen the scope.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 11:30 AM, Torsten Zuehlsdorff wrote:

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to 
handle the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy 
to maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the 
upgrade path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - 
they just hurt you daily. :D




No not really I ran LFS servers and desktops for 10 years

Having a "releng ports" version that goes with a releng version of 
the OS would be great by me.   Linux from scratch does this and it 
works very well. 


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, 
because at one you have PHP 7 and on the other MySQL 5.7, but not both 
at the same Ubuntu version.


BSD != Linux so your comparison is invalid.

One could still use releng 11.0 ports with 10.3 OS could they not

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Julian Elischer]

On 22/6/17 10:16 pm, Baptiste Daroussin wrote:

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:


As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)
Yeah but the quarterly branches are relatively useless because they a 
not sync'd to anything and mean nothing special to anyone.
As soon as you sync to one, it's deleted and replaced by a completely 
different one meaning you have to replace *EVERYTHING*,

so one might as well just use head. it's actually easier.




Best regards,
Bapt



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:

>On 2017/06/22 15:03, scratch65...@att.net wrote:
>> Why don't the same choices apply here?  What am I missing?
>
>Two things:
>
>  1) It's progress in the development of the FreeBSD base system that
>drives the release cycle.  The general state of the ports does not exert
>much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied. 

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?

So where's the point in everyone going mad trying to keep up a
quarterly release schedule that serves more as an annoyance than
benefit to your customer base?  (Do you read the Asterix comics?
The one where Asterix and Obelix go to Switzerland is
particularly apropos here, I think:  the owner of the inn awakens
the guests every hour so that they can turn over the hourglass
mounted over their bed.  What benefit do the guests derive from
that?  None, of course, but it helps the owner feel in control of
things.  But the guests are, reasonably, quite upset by the loss
of sleep due to his obsessiveness.)


>
>  2) Even if we could scrape up enough people to support however many
>branches you are proposing, remember they are all volunteers.  It's hard
>enough getting people to maintain the existing quarterly branches as it
>is, and those are relatively short lived so that most merges from head
>are pretty trivial.  People really aren't going to want to do
>essentially repetitive merges to branches where everything else is up to
>X years older than head.  Which would make it both tedious and
>frequently difficult to do.

Again I'm really not following your logic.   There are 2 versions
of the base system now in play:  10.3 and 11.0.  There are 2 more
being developed: 10.4 and 11.1.   10.2 has already been trashed,
thus forcing us to upgrade to 10.3 whether we wanted to or not,
which in many cases, mine among them, was a "not".  I'm sure the
same thing will happen with 10.4 and 11.1 and plenty folk will be
just as annoyed as we were with 10.2

Let's say you guys don't try to follow that schedule.  You do a
ports release for (let's say) 10.0 and then 11.0, but not for the
other point releases in between.  So if someone feels the deep
need for 10.1, or 10.2, or 10.3 (or 11.n mutatis mutandis),
they'll run 10.0 (or 11.0)  ports under it.   It's done all the
time in industry.   If you treat each ports release as a DVD
--immutable once shipped--, or as a PROM, where changes can be
made but it's a pain in the dupa so you only do it for the
emergency case, it seems to me that the pressure has gone down by
a factor of  3 or so.  So where's the problem in that? 

's mise le meas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Torsten Zuehlsdorff]

On 22.06.2017 21:26, Baho Utot wrote:

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

As usual with such proposal, where do you find the manpower to handle 
the number
of branches required (the quarterly branches are already hard to 
maintain, it is

only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


Go ahead with whatever fits your needs.

But since the ports-tree is a subversion repository it is really easy to 
maintain the status you want. I do this for various customer and my 
various server.


I am looking for a system that is very stable and doesn't do the upgrade 
path for the sake of it being newer.


Which has various downsides. I remember for example various linux LTS 
distros, which only apply security fixes. I discovered various bugs 
which stay there for years, because they are not security issues - they 
just hurt you daily. :D


Having a "releng ports" version that goes with a releng version of the 
OS would be great by me.   Linux from scratch does this and it works 
very well.  


It really does not work well. In everyday situation this results in 
"heck we need a new server to get a new version of a needed software, 
because we need a new linux version".
I regularly seeing admins setting up different Ubuntu versions, because 
at one you have PHP 7 and on the other MySQL 5.7, but not both at the 
same Ubuntu version.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baho Utot]

On 6/22/2017 10:03 AM, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:


As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___




I am looking at OpenBSD to replace FreeBSD.  They have a more relaxed 
update schedule and that fits with what I need.


I am looking for a system that is very stable and doesn't do the upgrade 
path for the sake of it being newer.


Having a "releng ports" version that goes with a releng version of the 
OS would be great by me.   Linux from scratch does this and it works 
very well.  Why not have the ports system mirror the OS system?  Could 
it not be done by using branches in subversion?  Of course if changed it 
would have to mature out a little.


If the laptop that I have under testing pans out I be gone.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Matthew Seaman]

On 2017/06/22 15:03, scratch65...@att.net wrote:
> Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

  2) Even if we could scrape up enough people to support however many
branches you are proposing, remember they are all volunteers.  It's hard
enough getting people to maintain the existing quarterly branches as it
is, and those are relatively short lived so that most merges from head
are pretty trivial.  People really aren't going to want to do
essentially repetitive merges to branches where everything else is up to
X years older than head.  Which would make it both tedious and
frequently difficult to do.

Tedious and difficult generally means "you need to pay someone to do
that".  Which means you need a commercial setup to generate the money to
pay all those wages.  Which means you -- the end user -- get to pay for
the provision of those specially maintained package sets.

Now, if you think you have a viable business case for maintaining
essentially a static snapshot-plus-security-fixes of the ports and
supplying packages generated from it, by all means go ahead and try
offering that as a commercial service.  I doubt you'll succeed though --
a number of other people[*] have been down that path, and they usually
give up fairly early because the market just won't support it at the moment.

Cheers,

Matthew

[*] These guys most recently:
http://www.xinuos.com/menu-products/openserver-10  They're still going,
but I haven't heard of much activity from them for the last year or so.




signature.asc
Description: OpenPGP digital signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

2017-06-22 16:16 GMT+02:00 Baptiste Daroussin :
> The model with one branch per release will bring it to way more with a
> maintenance window way larger (actually it is 3 month making the quarterly
> relatively easy to maintain)

So after three months if you don't switch branch, you're outdated
since bugfixes are not applied in old ones. Then we get back into the
same trouble of major upgrades while the user just wanted to have
security updates.

-- 
Demelier David
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 10:03:33AM -0400, scratch65...@att.net wrote:
> [Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
>  wrote:
> 
> >As usual with such proposal, where do you find the manpower to handle the 
> >number
> >of branches required (the quarterly branches are already hard to maintain, 
> >it is
> >only one branch).
> 
> Please help me out here, Baptiste, because I'm apparently missing
> *something*.   
> 
> Out in industry, if you haven't enough people to do a new
> high-quality release every N months, and you can't get a
> headcount increase, then you cut the release schedule.  Can't do
> 4 releases a year?  Cut back to 2.  Still too many?  Cut back to
> 1.
> 
> The alternatives to cutting the schedule are that (a) people
> begin burning out and quitting, (b) quality drops and your
> customer base begins abandoning you, or (c) both of the above.
> 
> Why don't the same choices apply here?  What am I missing?

We only have 1 quarterly branch at the time :)

The model with one branch per release will bring it to way more with a
maintenance window way larger (actually it is 3 month making the quarterly
relatively easy to maintain)

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[scratch65535]

[Default] On Thu, 22 Jun 2017 14:18:56 +0200, Baptiste Daroussin
 wrote:

>As usual with such proposal, where do you find the manpower to handle the 
>number
>of branches required (the quarterly branches are already hard to maintain, it 
>is
>only one branch).

Please help me out here, Baptiste, because I'm apparently missing
*something*.   

Out in industry, if you haven't enough people to do a new
high-quality release every N months, and you can't get a
headcount increase, then you cut the release schedule.  Can't do
4 releases a year?  Cut back to 2.  Still too many?  Cut back to
1.

The alternatives to cutting the schedule are that (a) people
begin burning out and quitting, (b) quality drops and your
customer base begins abandoning you, or (c) both of the above.

Why don't the same choices apply here?  What am I missing?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

2017-06-22 14:18 GMT+02:00 Baptiste Daroussin :
> On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> As usual with such proposal, where do you find the manpower to handle the 
> number
> of branches required (the quarterly branches are already hard to maintain, it 
> is
> only one branch).

I think release branches won't need much maintainance as unless a
security issue is found, no updates are necessary.

> What do you do for security fixes: backport to the stable version? who is
> backporting to software not maintained upstream any more in the given branch?
>

I would never backport anything. It's quite the opposite. If a
security flaw is discovered in let say: OpenSSL; then we check if it's
present in the release branch and top port in quarterly then HEAD if
they are also affected by this issue.

Regarding your second mail, the question may also apply on HEAD :-)

Cheers,

-- 
Demelier David
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Vlad K.]

On 2017-06-22 14:15, David Demelier wrote:


While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:


What works best for us, to keep a stable production, is to track the 
HEAD with svn. That way we can pre-empt changes locally, test, and 
deploy into production, or block upstream changes by keeping some older 
version until something else is fixed.


Otherwise as others have suggested, the problem is manpower and 
backporting patches. Although, in my experience having run both Ubuntu 
LTS and FreeBSD in production, when a maintainer, who is not the 
developer of some software, tries to backport patches, it often results 
in regressions and even more problems introduced. So I'd rather use 
rolling release directly from the developers with minimal local changes.


A rolling release with clearly marked stable versions kept longer around 
(ala Gentoo), is the best way to solve the problem with ports without 
introducing extra manpower and the need to backport.




--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:18:56PM +0200, Baptiste Daroussin wrote:
> On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> > Hello,
> > 
> > Today I've upgraded one of my personal FreeBSD servers. It's running
> > FreeBSD 11.0 for a while.
> > 
> > While I use quarterly ports branches, I usually update my ports tree
> > before installing a new service and I faced some troubles:
> > 
> > www/node was updated from 6.x to 7.x: unfortunately my etherpad
> > instance is not compatible with 7.x. I needed to install www/node6.
> > 
> > devel/mercurial was updated to 4.2: redmine has a small issue making
> > repository browsing unavailable. I temporarily downgraded Mercurial to
> > 4.0.
> > 
> > I think the current process of having rolling-releases packages makes
> > unpredictable upgrades as we have to manually check if the upgrade
> > will be fine or not. When a user installs FreeBSD 11.0 on its system,
> > it probably expects that everything will work fine until a next major
> > upgrade like 12.0. That's why I think we really should implement
> > branches for a specific FreeBSD version.
> > 
> > When FreeBSD 12.0 is released, we should create a ports branch that
> > will contains only fixes (such as security advisories, crash fixes and
> > such). No minor or major upgrades until a new 13.0 version is
> > released. This is the only way to make safe upgrades.
> > 
> > If user think that a software is too old (since we have long delay
> > between major releases) it can still use the default tree at its own
> > risks.
> > 
> > Additional benefits of having a ports tree by version: you don't need
> > to have conditionals in ports Makefiles (how many ports check for
> > FreeBSD version? a lot).
> > 
> > Any comments are appreciated.
> 
> As usual with such proposal, where do you find the manpower to handle the 
> number
> of branches required (the quarterly branches are already hard to maintain, it 
> is
> only one branch).
> 
> What do you do for security fixes: backport to the stable version? who is
> backporting to software not maintained upstream any more in the given branch?
> 
> Bapt

Oh and of course the day you freeze a branch you will have complain about "how
do I get python 3.8 on freebsd 11.0"

Bapt


signature.asc
Description: PGP signature

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Fernando Apesteguía]

El 22 jun. 2017 14:15, "David Demelier"  escribió:

Hello,

Today I've upgraded one of my personal FreeBSD servers. It's running
FreeBSD 11.0 for a while.

While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:

www/node was updated from 6.x to 7.x: unfortunately my etherpad
instance is not compatible with 7.x. I needed to install www/node6.

devel/mercurial was updated to 4.2: redmine has a small issue making
repository browsing unavailable. I temporarily downgraded Mercurial to
4.0.

I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.

If user think that a software is too old (since we have long delay
between major releases) it can still use the default tree at its own
risks.

Additional benefits of having a ports tree by version: you don't need
to have conditionals in ports Makefiles (how many ports check for
FreeBSD version? a lot).

Any comments are appreciated.

Regards,


CMIIW but when similar approaches come up, one of the reasons to not do it
is man power.


--
Demelier David
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] Why FreeBSD ports should have branches by OS version

[Baptiste Daroussin]

On Thu, Jun 22, 2017 at 02:15:02PM +0200, David Demelier wrote:
> Hello,
> 
> Today I've upgraded one of my personal FreeBSD servers. It's running
> FreeBSD 11.0 for a while.
> 
> While I use quarterly ports branches, I usually update my ports tree
> before installing a new service and I faced some troubles:
> 
> www/node was updated from 6.x to 7.x: unfortunately my etherpad
> instance is not compatible with 7.x. I needed to install www/node6.
> 
> devel/mercurial was updated to 4.2: redmine has a small issue making
> repository browsing unavailable. I temporarily downgraded Mercurial to
> 4.0.
> 
> I think the current process of having rolling-releases packages makes
> unpredictable upgrades as we have to manually check if the upgrade
> will be fine or not. When a user installs FreeBSD 11.0 on its system,
> it probably expects that everything will work fine until a next major
> upgrade like 12.0. That's why I think we really should implement
> branches for a specific FreeBSD version.
> 
> When FreeBSD 12.0 is released, we should create a ports branch that
> will contains only fixes (such as security advisories, crash fixes and
> such). No minor or major upgrades until a new 13.0 version is
> released. This is the only way to make safe upgrades.
> 
> If user think that a software is too old (since we have long delay
> between major releases) it can still use the default tree at its own
> risks.
> 
> Additional benefits of having a ports tree by version: you don't need
> to have conditionals in ports Makefiles (how many ports check for
> FreeBSD version? a lot).
> 
> Any comments are appreciated.

As usual with such proposal, where do you find the manpower to handle the number
of branches required (the quarterly branches are already hard to maintain, it is
only one branch).

What do you do for security fixes: backport to the stable version? who is
backporting to software not maintained upstream any more in the given branch?

Bapt


signature.asc
Description: PGP signature

[RFC] Why FreeBSD ports should have branches by OS version

[David Demelier]

Hello,

Today I've upgraded one of my personal FreeBSD servers. It's running
FreeBSD 11.0 for a while.

While I use quarterly ports branches, I usually update my ports tree
before installing a new service and I faced some troubles:

www/node was updated from 6.x to 7.x: unfortunately my etherpad
instance is not compatible with 7.x. I needed to install www/node6.

devel/mercurial was updated to 4.2: redmine has a small issue making
repository browsing unavailable. I temporarily downgraded Mercurial to
4.0.

I think the current process of having rolling-releases packages makes
unpredictable upgrades as we have to manually check if the upgrade
will be fine or not. When a user installs FreeBSD 11.0 on its system,
it probably expects that everything will work fine until a next major
upgrade like 12.0. That's why I think we really should implement
branches for a specific FreeBSD version.

When FreeBSD 12.0 is released, we should create a ports branch that
will contains only fixes (such as security advisories, crash fixes and
such). No minor or major upgrades until a new 13.0 version is
released. This is the only way to make safe upgrades.

If user think that a software is too old (since we have long delay
between major releases) it can still use the default tree at its own
risks.

Additional benefits of having a ports tree by version: you don't need
to have conditionals in ports Makefiles (how many ports check for
FreeBSD version? a lot).

Any comments are appreciated.

Regards,

-- 
Demelier David
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"