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.
Received on Thu Oct 29 2015 - 13:37:41 UTC