~alpine/devel

17 7

[alpine-devel] v3.3 feature freeze

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20151022180104.1feeb73a@ncopa-laptop>
Sender timestamp
1445529664
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jose-Luis Rivas <ghostbar@riseup.net>
Details
Message ID
<20151022235036.GA10429@curie.resnullius.co>
In-Reply-To
<20151022180104.1feeb73a@ncopa-laptop> (view parent)
Sender timestamp
1445557836
DKIM signature
missing
Download raw message
On 22/10/15, 06:01pm, Natanael Copa wrote:
> 
> 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
Details
Message ID
<201510230304.36654.vkrishn4@gmail.com>
In-Reply-To
<20151022180104.1feeb73a@ncopa-laptop> (view parent)
Sender timestamp
1445549676
DKIM signature
missing
Download raw message
> 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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20151023092913.2cac7018@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20151022235036.GA10429@curie.resnullius.co> (view parent)
Sender timestamp
1445585353
DKIM signature
missing
Download raw message
On Thu, 22 Oct 2015 19:50:36 -0400
Jose-Luis Rivas <ghostbar@riseup.net> wrote:

> On 22/10/15, 06:01pm, Natanael Copa wrote:
> > 
> > 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20151026101227.2e9e3058@ncopa-desktop.alpinelinux.org>
In-Reply-To
<201510230304.36654.vkrishn4@gmail.com> (view parent)
Sender timestamp
1445850747
DKIM signature
missing
Download raw message
On Fri, 23 Oct 2015 03:04:36 +0530
"V.Krishn" <vkrishn4@gmail.com> wrote:

> > 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?
> 
> 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.

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.

> 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.

What about those packages?

> 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 ?

Something like that yes.

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

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?)

> 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)

Lets take that discussion after v3.3. We are unfortunally running out
of time for v3.3 release.
 
> What if 2+3 had boot options - grsec vanilla ?
> Will this help in not creating the smaller sized vanilla and xen isos ?

to late for this kind of changes now.
 
> Comments welcome.
> 

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1445872834.3455.43.camel@df1844j>
In-Reply-To
<20151026101227.2e9e3058@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1445872834
DKIM signature
missing
Download raw message
On lun, 2015-10-26 at 10:12 +0100, Natanael Copa wrote:
> On Fri, 23 Oct 2015 03:04:36 +0530
> "V.Krishn" <vkrishn4@gmail.com> wrote:
> 
> > > 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?
> > 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.

> > 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 ?
> 
> Something like that yes.
> 
> > Based on 2 above, I can spot (debatable though), 
> >  zabbix, nagios, wayland
> 
> I think we want atleast zabbix and nagios to stay in main.
> 

+1

> 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?)
> 
> > 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)
> 
> Lets take that discussion after v3.3. We are unfortunally running out
> of time for v3.3 release.
>  
> > What if 2+3 had boot options - grsec vanilla ?
> > Will this help in not creating the smaller sized vanilla and xen isos ?
> 
> to late for this kind of changes now.
>  
> > Comments welcome.
> > 
> 
> -nc
> 

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

Thanks!

- leo
Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20151027021046.GA6443@newbook>
In-Reply-To
<20151026101227.2e9e3058@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1445911847
DKIM signature
missing
Download raw message
On Mon, Oct 26, 2015 at 10:12:27AM +0100, Natanael Copa wrote:
> On Fri, 23 Oct 2015 03:04:36 +0530
> "V.Krishn" <vkrishn4@gmail.com> wrote:
> > Based on 2 above, I can spot (debatable though), 
> >  zabbix, nagios, wayland
> 
> 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?)

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20151027085352.39153888@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20151027021046.GA6443@newbook> (view parent)
Sender timestamp
1445932432
DKIM signature
missing
Download raw message
On Mon, 26 Oct 2015 19:10:47 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Mon, Oct 26, 2015 at 10:12:27AM +0100, Natanael Copa wrote:
> > On Fri, 23 Oct 2015 03:04:36 +0530
> > "V.Krishn" <vkrishn4@gmail.com> wrote:
> > > Based on 2 above, I can spot (debatable though), 
> > >  zabbix, nagios, wayland
> > 
> > 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?)
> 
> 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...)

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.


> HTH,
> Isaac Dunham

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1445958095.9302.5.camel@df1844j>
In-Reply-To
<1445872834.3455.43.camel@df1844j> (view parent)
Sender timestamp
1445958095
DKIM signature
missing
Download raw message
On lun, 2015-10-26 at 16:20 +0100, Leonardo Arena wrote:

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

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

- leo
Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20151028031310.GB2481@newbook>
In-Reply-To
<1445958095.9302.5.camel@df1844j> (view parent)
Sender timestamp
1446001991
DKIM signature
missing
Download raw message
On Tue, Oct 27, 2015 at 04:01:35PM +0100, Leonardo Arena wrote:
> 
> On lun, 2015-10-26 at 16:20 +0100, Leonardo Arena wrote:
> 
> > I'll try to come up with list of packages that we could consider moving
> > to community.
> > 
> 
> Attached is a proposed list, which is by no means complete. None of the
> listed packages have dependencies on main.
> 
> - leo

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Christian Kampka <christian@kampka.net>
Details
Message ID
<CADq4isQa0YK+q-D=Aja576fdh2fJqyLNNqDBeVKhd8uj_sQbyw@mail.gmail.com>
In-Reply-To
<20151028031310.GB2481@newbook> (view parent)
Sender timestamp
1446030771
DKIM signature
missing
Download raw message
>
> execline
>  - the scripting language recommended by the s6 author; it probably
>  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.
Laurent Bercot <ska-devel@skarnet.org>
Details
Message ID
<5630B7AA.3030607@skarnet.org>
In-Reply-To
<CADq4isQa0YK+q-D=Aja576fdh2fJqyLNNqDBeVKhd8uj_sQbyw@mail.gmail.com> (view parent)
Sender timestamp
1446033322
DKIM signature
missing
Download raw message
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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1446033988.9302.13.camel@df1844j>
In-Reply-To
<5630B7AA.3030607@skarnet.org> (view parent)
Sender timestamp
1446033988
DKIM signature
missing
Download raw message
On mer, 2015-10-28 at 12:55 +0100, Laurent Bercot wrote:
> 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. :)
> 

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
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1446105556.9302.26.camel@df1844j>
In-Reply-To
<201510291311.01965.vkrishn4@gmail.com> (view parent)
Sender timestamp
1446105556
DKIM signature
missing
Download raw message
On gio, 2015-10-29 at 13:11 +0530, V.Krishn wrote:
> > On lun, 2015-10-26 at 10:12 +0100, Natanael Copa wrote:
> > > On Fri, 23 Oct 2015 03:04:36 +0530
> > > 
> > > "V.Krishn" <vkrishn4@gmail.com> wrote:
> > > > > 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?
> > > > 
> > > > 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.
> > > 
> > > 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.
> > > 
> > > > 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.
> > > 
> > > 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.
> 
> 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.
> 

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
Details
Message ID
<201510291311.01965.vkrishn4@gmail.com>
In-Reply-To
<1445872834.3455.43.camel@df1844j> (view parent)
Sender timestamp
1446104461
DKIM signature
missing
Download raw message
> On lun, 2015-10-26 at 10:12 +0100, Natanael Copa wrote:
> > On Fri, 23 Oct 2015 03:04:36 +0530
> > 
> > "V.Krishn" <vkrishn4@gmail.com> wrote:
> > > > 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?
> > > 
> > > 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.
> > 
> > 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.
> > 
> > > 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.
> > 
> > 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.

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.

> 
> > > 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 ?
> > 
> > Something like that yes.
> > 
> > > Based on 2 above, I can spot (debatable though),
> > > 
> > >  zabbix, nagios, wayland
> > 
> > I think we want atleast zabbix and nagios to stay in main.
> 
> +1
> 
> > 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?)
> > 
> > > 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)
> > 
> > Lets take that discussion after v3.3. We are unfortunally running out
> > of time for v3.3 release.
> > 
> > > What if 2+3 had boot options - grsec vanilla ?
> > > Will this help in not creating the smaller sized vanilla and xen isos ?
> > 
> > to late for this kind of changes now.
> > 
> > > Comments welcome.
> > 
> > -nc
> 
> I'll try to come up with list of packages that we could consider moving
> to community.
> 
> Thanks!
> 
> - leo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1446122261.9302.50.camel@df1844j>
In-Reply-To
<201510291624.21420.vkrishn4@gmail.com> (view parent)
Sender timestamp
1446122261
DKIM signature
missing
Download raw message
On gio, 2015-10-29 at 16:24 +0530, V.Krishn wrote:
> > On gio, 2015-10-29 at 13:11 +0530, V.Krishn wrote:
> > > 
> > > 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.
> > 
> > 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?
> 
> 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 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.


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

+1

- leo
Leonardo Arena <rnalrd@gmail.com>
Details
Message ID
<1446125375.9302.59.camel@df1844j>
In-Reply-To
<20151028031310.GB2481@newbook> (view parent)
Sender timestamp
1446125375
DKIM signature
missing
Download raw message
On mar, 2015-10-27 at 20:13 -0700, Isaac Dunham wrote:
> On Tue, Oct 27, 2015 at 04:01:35PM +0100, Leonardo Arena wrote:
> > 
> > On lun, 2015-10-26 at 16:20 +0100, Leonardo Arena wrote:
> > 
> > > I'll try to come up with list of packages that we could consider moving
> > > to community.
> > > 
> > 
> > Attached is a proposed list, which is by no means complete. None of the
> > listed packages have dependencies on main.
> > 
> > - leo
> 
> 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.)
> 
> 

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
Details
Message ID
<201510291624.21420.vkrishn4@gmail.com>
In-Reply-To
<1446105556.9302.26.camel@df1844j> (view parent)
Sender timestamp
1446116061
DKIM signature
missing
Download raw message
> On gio, 2015-10-29 at 13:11 +0530, V.Krishn wrote:
> > > On lun, 2015-10-26 at 10:12 +0100, Natanael Copa wrote:
> > > > On Fri, 23 Oct 2015 03:04:36 +0530
> > > > 
> > > > "V.Krishn" <vkrishn4@gmail.com> wrote:
> > > > > > 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?
> > > > > 
> > > > > 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.
> > > > 
> > > > 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.
> > > > 
> > > > > 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.
> > > > 
> > > > 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.
> > 
> > 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.
> 
> 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?

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)