X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 8C0E9DC0DF7 for ; Fri, 17 Jul 2015 18:58:00 +0000 (UTC) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 55D70DC0CC4 for ; Fri, 17 Jul 2015 18:58:00 +0000 (UTC) Received: by iecuq6 with SMTP id uq6so83324109iec.2 for ; Fri, 17 Jul 2015 11:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4rUpl3vr9NKbBIgJgq9IXYGzS45OkLZXLWF9A4wousE=; b=MCD1DjCLhbkPFscg7R/wk9n+VLLe7Xwg/5sFjY2A1AqnBtq2vwnRxoG2VYm6QOHazH +EnpYH/iLHUAMD4ZkOVN3rT98XhacRFwkYEIHw0epCvM4GDu33oMDWlnC6Tya60NgzeK nRnHt7DJHU/RuowzlfGJ3km0uExtKK5qmW2Z602e9lr3+n7ryoWDcTWOvUyuEbzW/PAQ osjlY+y9eFcbxnk2rGIOysyiWifYLwgZyLu4OgWaUkeNMbzdHHeqoruHmDybcCtcvFAw 90vDidzhvy/SNqaB7lhOvFS4Xhl+6SQEhVJsw5/bSIdwX+7m+7cl7AfxlGxkIyqHd1WE RXqA== X-Received: by 10.107.6.87 with SMTP id 84mr19883621iog.35.1437159479526; Fri, 17 Jul 2015 11:57:59 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.79.36.13 with HTTP; Fri, 17 Jul 2015 11:57:40 -0700 (PDT) In-Reply-To: <20150717165916.5f26f656@ncopa-desktop.alpinelinux.org> References: <20150717165916.5f26f656@ncopa-desktop.alpinelinux.org> From: Alan Messias Date: Fri, 17 Jul 2015 15:57:40 -0300 Message-ID: Subject: Re: [alpine-devel] reorganize the repositories To: Natanael Copa Cc: alpine-devel@lists.alpinelinux.org Content-Type: multipart/alternative; boundary=001a113ee9aa434bdc051b16c491 X-Virus-Scanned: ClamAV using ClamSMTP --001a113ee9aa434bdc051b16c491 Content-Type: text/plain; charset=UTF-8 Natanael, I lilke the idea of *staging and then move to 'main' or to 'community' repo*. But just to make sure it is clear, let me quote you: " > *People in community group may git push to 'community' repo but not* > *'main' repo. This is so that maintainers can push packages themselves,**without > needing to send patches, like they currently do.*" Does it mean that *everybody *that asks for write access in 'community' will be accepted to git push to it? In case of an 'yes', this is the piece that I don't like - I'd vote to everybody continue sending patches to 'community' except some approved ones. Another quote ref. staging repo: " > *We might want autopurge packages that has not been moved to 'main' > or'community' repo*" It might be great! But i think we'll need to keep track of packages purged just in case someone requests a package that were in staging for a period and was purged - Or any other way to avoid that we fall in a loop adding package and purging it over and over again (nowadays there are packages in testing being used for users and, it may happen that, once we purge it, the user will miss the package and request *new [old]* package). " > *We could also give maintainers git push access to only the packages* > *they maintain, but I think that would complicate things more than* > *needed.*" I agree with you - I wouldn't vote to use this. About the 'staging' repo: I like this name but I also like NetBSD's idea of *wip* (stands for *w*ork *i*n *p*rogress). Maybe staging could be called *wip* repository. :wq! alacerda On Fri, Jul 17, 2015 at 11:59 AM, Natanael Copa wrote: > Hi, > > The 'main' repository has grown big. > > I feel that we have more packages than we can maintain for 2 years. I > don't mind that we have tons of packages, but there are many packages > that I only want give best-effort support for security fixes instead of > supporting it for 2 years. > > Too many files/dirs in a directory is not good for performance also. > > So the idea is to split main, or reorganize the repositories as: > > - main > All core packages and all the package that we can provide 2 year > support for. > > - community > All the extra packages that community maintains. This repository will > be available in stable releases but we only provide best-effort > support for bug and security fixes. None of the packages in 'main' > repository can depend on anything in 'community'. > > - staging > This is basically current 'testing', but we rename it to make it > clear that packages are not supposed to stay here forever. We might > want autopurge packages that has not been moved to 'main' or > 'community' repo. Once a package is tested and confirmed to work, it > can be moved to either community or main. > > We would have a gitolite group, 'maindevs' and another 'communitydevs'. > People in community group may git push to 'community' repo but not > 'main' repo. This is so that maintainers can push packages themselves, > without needing to send patches, like they currently do. The recent > move to gitolite makes this possible. > > We could also give maintainers git push access to only the packages > they maintain, but I think that would complicate things more than > needed. > > Other alternatives is that we introduce categories ala gentoo, and the > bsd ports, but I would prefer avoid this. We'd need to decide what > package belongs in what category. They can often fit into many. > > What do you think? > > Other ideas? > > -nc > > > --- > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > Help: alpine-devel+help@lists.alpinelinux.org > --- > > -- Atenciosamente, Alan Messias Cordeiro *The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for. -- A. Tanenbaum, "Introduction to Computer Networks"* --001a113ee9aa434bdc051b16c491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Natanael,

I lilke the idea of stagin= g and then move to 'main' or to 'community' r= epo. But just to make sure it is clear, let me quote you:
"People in community group may git push to = 'community' repo but not
'main' repo. This is so = that maintainers can push packages themselves,
without needing to= send patches, like they currently do."

Does it mean that everybody that asks for write access in '= ;community' will be accepted to git push to it? In case of an 'yes&= #39;, this is the piece that I don't like - I'd vote to everybody c= ontinue sending patches to 'community' except some approved ones.

Another quote ref. staging repo:

"We= might=C2=A0want autopu= rge packages that has not been moved to 'main' or
'community' repo
&q= uot;

It might be great! But i think we'= ll need to keep track of packages purged just in case someone requests a pa= ckage that were in staging for a period and was purged - Or any other way t= o avoid that we fall in a loop adding package and purging it over and over = again (nowadays there are packages in testing being used for users and, it = may happen that, once we purge it, the user will miss the package and reque= st new [old] package).

"We could also give maintainers git push access to only the packages
they maintain, but I think that would complicate things more than
needed."

I agree with you - I= wouldn't vote to use this.

About the 'sta= ging' repo: I like this name but I also like NetBSD's idea of wi= p (stands for work in progress). Maybe staging cou= ld be called wip repository.

:wq!
alacerda

On Fri, Jul 17, 2015 at 11:59 AM, Natanael Copa <ncopa@a= lpinelinux.org> wrote:
Hi,

The 'main' repository has grown big.

I feel that we have more packages than we can maintain for 2 years. I
don't mind that we have tons of packages, but there are many packages that I only want give best-effort support for security fixes instead of
supporting it for 2 years.

Too many files/dirs in a directory is not good for performance also.

So the idea is to split main, or reorganize the repositories as:

- main
=C2=A0 All core packages and all the package that we can provide 2 year
=C2=A0 support for.

- community
=C2=A0 All the extra packages that community maintains. This repository wil= l
=C2=A0 be available in stable releases but we only provide best-effort
=C2=A0 support for bug and security fixes. None of the packages in 'mai= n'
=C2=A0 repository can depend on anything in 'community'.

- staging
=C2=A0 This is basically current 'testing', but we rename it to mak= e it
=C2=A0 clear that packages are not supposed to stay here forever. We might<= br> =C2=A0 want autopurge packages that has not been moved to 'main' or=
=C2=A0 'community' repo. Once a package is tested and confirmed to = work, it
=C2=A0 can be moved to either community or main.

We would have a gitolite group, 'maindevs' and another 'communi= tydevs'.
People in community group may git push to 'community' repo but not<= br> 'main' repo. This is so that maintainers can push packages themselv= es,
without needing to send patches, like they currently do. The recent
move to gitolite makes this possible.

We could also give maintainers git push access to only the packages
they maintain, but I think that would complicate things more than
needed.

Other alternatives is that we introduce categories ala gentoo, and the
bsd ports, but I would prefer avoid this. We'd need to decide what
package belongs in what category. They can often fit into many.

What do you think?

Other ideas?

-nc


---
Unsubscribe:=C2=A0 alpine-devel+unsubscribe@lists.alpinelinux.or= g
Help:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpine-devel+help@lists.alpineli= nux.org
---




--
Atenciosamente,
Alan Messias Cordeiro

The nice thing about standards is that= there are so many to choose from. And if you really don't like all the= standards you just have to wait another year until the one arises you are = looking for.=C2=A0--=C2=A0A. Tanen= baum, "Introduction to Comput= er Networks"

--001a113ee9aa434bdc051b16c491-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---