Subject: [alpine-devel] v3.3 feature freeze

From: Natanael Copa <[email-masked]>
Date: Thu, 22 Oct 2015 18:01:04 +0200

Hi,

We now need to stop working on new features for the v3.3 release and
concentrate on wrapping things up for v3.3 release. Testing and fixing
bugs.

A few questions:

Can we make the 'lua' package be lua5.3? I think everything that needs
5.1 should have depends on 'lua5.1' instead of 'lua'.

Can anyone help with upgrading llvm-3.7 and clang?

Can anyone help with upgrade xen to 4.6?

I'd like to move as much ruby stuff as possible to community, can
someone help with that?

Are there anything else that needs cleanup for v3.3?

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: "V.Krishn" <[email-masked]>
Date: Fri, 23 Oct 2015 03:04:36 +0530

> Are there anything else that needs cleanup for v3.3?

Any thoughts on:
1. All desktops except one that we want to keep as default and ready to jump 
on it to fix when update available or broken.
2. Web application like drupal, phpmyadmin, owncloud i.e pkgs that does not 
require compiling and are sometimes more easier to install by downloading the 
orig tar and just uncompressing in web-folders.

More pkgs can be picked based on definition and difference
 in community and main (please expand)
1. main requires 2yrs maintenance skill commitment.
2. main has higher priority when comes to pushing update/broken pkgs in next 
releases , right ?

Based on 2 above, I can spot (debatable though), 
 zabbix, nagios, wayland

This can also help in creating various isos, like
1. alpine-boot (bootable+live+AL preferred net tools/utils)
    media that gets you started with bare alpine install
    (quite same as current alpine-mini)
2. alpine-cd (same above + main) - non-desktop
2a. alpine-cd2 (anything in main if above 700mb)
...
3. alpine-dvd (1+2+2a+community)

What if 2+3 had boot options - grsec vanilla ?
Will this help in not creating the smaller sized vanilla and xen isos ?

Comments welcome.

-- 
Regards.
V.Krishn

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 26 Oct 2015 10:12:27 +0100

On Fri, 23 Oct 2015 03:04:36 +0530

> on it to fix when update available or broken.

You mean move to community?

I'm all for moving as much as possible to community.

The question was more general, what more cleanup, more than just move
stuff to community, are *needed* before v3.3. Eg the critical stuff,
the things we can not forget.

> orig tar and just uncompressing in web-folders.

What about those packages?

> 2. main has higher priority when comes to pushing update/broken pkgs in next 

Something like that yes.

> Based on 2 above, I can spot (debatable though), 

I think we want atleast zabbix and nagios to stay in main.

Wayland can probably move to community, unless there is something that
depends on it that we want/need keep in main.

Would be great if the feedback would not include any kind of research
from my part (eg wayland is in the dependency chain of what packages?)

> 3. alpine-dvd (1+2+2a+community)

Lets take that discussion after v3.3. We are unfortunally running out
of time for v3.3 release.
 
> Will this help in not creating the smaller sized vanilla and xen isos ?

to late for this kind of changes now.

-nc

---

---

From: Isaac Dunham <[email-masked]>
Date: Mon, 26 Oct 2015 19:10:47 -0700

> from my part (eg wayland is in the dependency chain of what packages?)

If you build mesa with wayland support enabled (as we do), mesa and Xorg
depend on wayland. (IMHO, this feels wrong, but that's how upstream did
it...)

HTH,
Isaac Dunham

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 27 Oct 2015 08:53:52 +0100

On Mon, 26 Oct 2015 19:10:47 -0700

> depend on wayland. (IMHO, this feels wrong, but that's how upstream did

yes.

I think we want start from the other end, take toplevel deps (packages
that nothing depends on) and work downwards.

We could for example move mate-*?

We could also move xfce, but I don't think xfce causes much maintenance
work. It is a slow moving project.

-nc

---

---

From: Leonardo Arena <[email-masked]>
Date: Mon, 26 Oct 2015 16:20:34 +0100

> What about those packages?

I think we should move to community the packages which don't have stable
and maintained releases. This is not the case of ownCloud since is
maintained for 1,5 years after release. For example v6.0.0 was released
in Dec. 2013 and last update was 6.0.9 on July 2016. v7.0.0 was released
July 2014 it's still actively maintained.

I think it's handy to have web applications packages for run-from-RAM
installations. Also upgrade of packaged web application is faster then
tar-based installations.

Not sure about drupal maintenance policy, and may be phpmyadmin can be
likely moved.

> I think we want atleast zabbix and nagios to stay in main.

+1

> to late for this kind of changes now.

I'll try to come up with list of packages that we could consider moving
to community.

Thanks!

- leo

---

From: Leonardo Arena <[email-masked]>
Date: Tue, 27 Oct 2015 16:01:35 +0100

> I'll try to come up with list of packages that we could consider moving

Attached is a proposed list, which is by no means complete. None of the
listed packages have dependencies on main.

- leo

---

From: Isaac Dunham <[email-masked]>
Date: Tue, 27 Oct 2015 20:13:11 -0700

> listed packages have dependencies on main.

I'd like to object to the following:
a2ps
brlaser
 - these are both important for printing; brlaser is the driver for my
   printer, and a2ps is the most versatile set of filters for cups
acf-*
 - these are the Alpine Configuration Framework packages, Alpine's web
 administration setup
b43-fwcutter
 - this is needed for using some wireless cards (all supported by b43)
bc
 - this calculator is required by POSIX and used to build the Linux kernel
execline
 - the scripting language recommended by the s6 author; it probably
 shouldn't be moved unless you plan to banish s6-* as well
aspell
 - needed for enchant, and thus most software using spell-checking
 (Abiword, webkitgtk, ...)
cracklib*
cvechecker
cutter
iftop
ipfw-*
...
 (essentially, all the network, password, and security stuff, for now.)
 ipfw is optional, but bandwidth monitoring, CVE checking, etc. are quite
 useful.
pssh
 - If I understand correctly, this allows one to use a single command for
 administering multiple systems.
 That should be enough to clarify how useful it is.
Others:
wipe, zonenotify

mplayer/mpv:
 - If we aren't *planning* on making all desktop-related stuff move to
 community, at least one of these (or another video player) is desireable
 in main.

Packages I'll second moving to community/:
pianobar
youtube-dl
 - These are high-churn tools that don't rely on a fixed remote API.

Additionally, I'm wondering it sword may be better off in community/,
since upstream is preparing 1.7.5 and may at some point "soon" release
1.8.0. (They have been working on it for years, and I have no idea how
close it is. Once that hits, 1.7.x will not be supported upstream.)

HTH,
Isaac Dunham

---

---

From: Christian Kampka <[email-masked]>
Date: Wed, 28 Oct 2015 11:12:51 +0000

>  shouldn't be moved unless you plan to banish s6-* as well

s6 has a build dependency on execline, so I'd say you have to move s6 as
well.

---

From: Laurent Bercot <[email-masked]>
Date: Wed, 28 Oct 2015 12:55:22 +0100

On 28/10/2015 12:12, Christian Kampka wrote:
> s6 has a build dependency on execline, so I'd say you have to move s6 as well.

  And if John doesn't want to maintain those in main anymore, I can
reasonably commit to doing it. :)

-- 
  Laurent

---

---

From: Leonardo Arena <[email-masked]>
Date: Wed, 28 Oct 2015 13:06:28 +0100

> reasonably commit to doing it. :)

I don't think we want to move s6 to community. It's just that "apk info
-r execline" didn't say that is needed by s6.

I'll do another pass checking "depends" in APKBUILDs.

- leo

---

From: Leonardo Arena <[email-masked]>
Date: Thu, 29 Oct 2015 14:29:35 +0100

> close it is. Once that hits, 1.7.x will not be supported upstream.)

A revised version liberally "inspired" by comments above :) and after
checking "depends" also.
As mentioned earlier this is just a proposal. It'd be nice to have the
respective maintainers' comments.

- leo

---

From: "V.Krishn" <[email-masked]>
Date: Thu, 29 Oct 2015 13:11:01 +0530

> > > > concentrate on wrapping things up for v3.3 release. Testing and
> > > > fixing bugs.
> > > > 
> > > > A few questions:
> > > > 
> > > > Can we make the 'lua' package be lua5.3? I think everything that
> > > > needs 5.1 should have depends on 'lua5.1' instead of 'lua'.
> > > > 
> > > 1. All desktops except one that we want to keep as default and ready to
> > > jump on it to fix when update available or broken.
> > 
> > > 2. Web application like drupal, phpmyadmin, owncloud i.e pkgs that does
> > > not require compiling and are sometimes more easier to install by
> > > downloading the orig tar and just uncompressing in web-folders.
> > 

Criteria is not upstream stability release but,
1. Does these pkgs' normal updates get backported ?
2. If we decide fitting main is one CD or two do we want them in main then ?
3. Pkgs like these are easy to maintain and maybe tagged/delegated to new or 
less experienced maintainers.
4. Note, there is no stopping for main devs in maintaining community pkgs.

> > > 2. main has higher priority when comes to pushing update/broken pkgs in
> > > next releases , right ?
> > 
> > Something like that yes.
> > 

---

---

From: Leonardo Arena <[email-masked]>
Date: Thu, 29 Oct 2015 08:59:16 +0100

> 4. Note, there is no stopping for main devs in maintaining community pkgs.

I think to it's one of the relevant criteria. Maintaining a package in a
stable Alpine branch, when upstream does not provide maintenance
releases, puts a load on the Alpine package maintainer that needs to
backport the security patches at least, and possibly other bugfixes too.

So I think one of the main questions to determine whether the package go
to main/community is:

- Is the maintainer willing to ensure that package foo-1.1.0 will have
~2years of security fixes/critical bug fixes available for version 1.1?
If yes, stay in main, if no, go to community, where you are free to bump
to version 2.x.
Or did I get the purpose of community repo wrong?

- leo

---

From: "V.Krishn" <[email-masked]>
Date: Thu, 29 Oct 2015 16:24:21 +0530

> > > > > > We now need to stop working on new features for the v3.3 release
> > > > > > and concentrate on wrapping things up for v3.3 release. Testing
> > > > > > and fixing bugs.
> > > > > > 
> > > > > > A few questions:
> > > > > > 
> > > > > 1. All desktops except one that we want to keep as default and
> > > > > ready to jump on it to fix when update available or broken.
> > > > 
> > > > > 2. Web application like drupal, phpmyadmin, owncloud i.e pkgs that
> > > > > does not require compiling and are sometimes more easier to
> > > > > install by downloading the orig tar and just uncompressing in
> > > > > web-folders.
> > > > 
> > > I think we should move to community the packages which don't have
> > > stable and maintained releases. This is not the case of ownCloud since
> > > is maintained for 1,5 years after release. For example v6.0.0 was
> > > released in Dec. 2013 and last update was 6.0.9 on July 2016. v7.0.0
> > > was released July 2014 it's still actively maintained.
> > > 
> > 2. If we decide fitting main is one CD or two do we want them in main
> > then ? 3. Pkgs like these are easy to maintain and maybe
> > tagged/delegated to new or less experienced maintainers.

Moving to community does not undermine maintainer's capability.
Nor does community undermines pkgs usability.
(users only needs to be a bit more aware while using those pkgs).
eg. if I were to pkg a group-ware like citadel.org I would let it stay in 
community, even if I can or am willing to do a "2years of security 
fixes/critical bug fixes".
Just thinking in terms of AL philosophy and things like "Small. Simple. 
Secure" , security-oriented, lightweight ...etc.

I think presently most important is if a main dev+maintainer thinks it goes in 
main/, that has overriding vote.

-- 
Regards.
V.Krishn

---

---

From: Leonardo Arena <[email-masked]>
Date: Thu, 29 Oct 2015 13:37:41 +0100

> Secure" , security-oriented, lightweight ...etc.

I didn't think much in these terms for community repo, although it makes
sense. I think the original idea why community repo was born, it's
because we want to diminish the backporting work to stable branches,
which is the harder part, and allowing more people to contribute/help
with maintenance by giving GIT write access.

To me community means "no maintenance releases, no system/core packages,
and possibly lower quality packaging". Main for me is instead
"system/core packages included but not only these, maintenances
releases, better packaging quality".

If maintainer wants to keep the package in community even though
upstream provide maintenance releases for ~2y, I'm fine with that.

And I don't have objections in having non-system/core packages in main,
as long as there are maintenance releases.

+1

- leo

---

From: Jose-Luis Rivas <[email-masked]>
Date: Thu, 22 Oct 2015 19:50:36 -0400

> Are there anything else that needs cleanup for v3.3?

Yes, nodejs definitely needs to be upgraded to v4.2.1, since v4.2.x is
LTS and v4.2.1 was just making the v4.2 right I think it would be wrong
to leave something less than that on v3.3. for 6 months.

There's a patch already sitting for this upgrade.

-- 
⨳ PGP 0x13EC43EEB9AC8C43 ⨳ https://ghostbar.co

---

From: Natanael Copa <[email-masked]>
Date: Fri, 23 Oct 2015 09:29:13 +0200

On Thu, 22 Oct 2015 19:50:36 -0400

> to leave something less than that on v3.3. for 6 months.

yes, we definitively want this in. thanks

> There's a patch already sitting for this upgrade.

git am failed, which is why it got delayed.

I have fixed it now and applied. thanks! (you will not get automatic
email notification on it due to i had to modify it)

-nc

---