Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Jose J. R. <jo...@gm...>]

I agree with most of what Tony proposes, but with uel's "fixes", lol.

I might be jumping ahead here, but I do think we should start planning
so the repo for VL6 has a better organization from the start, as
discussed previously, something like official, unofficial, extras,
unstable, etc, or any other naming convention. The thing is to
separate the maintenance packages (allowing for a possible
distro-update) from the extra apps and those which are development
releases of apps.

I must also restate my hope that beyond the base-cli bulk, the rest
can be handled as packages with metapackages to define the "bulks".
This would allow an "easy" install by selecting metapackages or an
"advanced" install where most apps are listed for selection (probably
not necessary to list libs) and the deps are handled automatically for
those selected. For this, slapt-get might be a good choice to consider
if it can be called from the installer in the initrd.

Regards,
Joe1962


On 4/6/06, uel archuletta <ue...@gm...> wrote:
> Sounds good. I have some additions to a few of your propositions. here th=
ay
> are
>
> 1. we have some package list we may be able to use to help in this they a=
re
> in ftp in the VL6base folder.
> 2. I nominate you to build the base and get it setup for us. :)
> 3. sounds good, but do we have enough people to seperate into 2 groups?
> 4. agree
> 5. agree
> 6. I along with others would like to see this borken down further. base-c=
li,
> dev, X, std, soho, some examples would be the package lists in VL6base on
> ftp.
> 7. I think there should be a seperation in release dates. 1 reason is
> Distrowatch another is easier for us to debug.
> 8.agree
> 9.agree
> 10.agree
> 11. see #7
> 12. I really like this idea
> 13. agree
> 14. agree
>
> some really good ideas here Tony.
> Thanks,
> Uel
>
>
> On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> > Sorry if this has already been decided upon but I haven't been made awa=
re
> of it so here goes.
> >
> > I have been looking at these as I'm sure some or all of you have as wel=
l.
> >
> > I think we can work with these to build our base from source and then
> expand on them in the future.
> >
> > There were a few of us on irc last night chatting about it.
> >
> > This is how I think we should move forward with this:
> >
> > 1 - as a group, decide on all the packages for both std vl and soho bef=
ore
> we start
> > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k sourc=
e
> trees) - probably either myself or Uel or anyone that wants to take
> ownership of this task - all base build scripts need to be corrected for
> arch,flags,etc
> > 3 - once the base is built, each developer is given a source tree or tr=
ees
> and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc - a=
ll
> packages must be built on a virgin base except for soho - 2 groups are
> needed here - std and soho and there will be some duplication as std and
> soho should be treated as separate distros - all build scripts need to
> corrected for arch,flags,etc
> > 4 - we need to come up with SlackBuilds for the packages we include tha=
t
> aren't in slack and split this up depending on how many pkgs there are
> > 5 - upload all the built packages to the respective trees and each of u=
s
> install them for testing.
> > 6 - once testing is completed, we package these up for the cd into
> vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages shou=
ld
> reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and hav=
e
> all packages built for it using kde as a dep.
> > 7 - release beta std and soho at the same time
> > 8 - set a beta test schedule of 2 weeks
> > 9 - fix and release rc
> > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stabl=
e.
> > 11 - release final std and soho at the same time.
> > 12 - designate a dev for each versions - std and soho - whose primary
> responsibility will be security patching
> > 13 - start working on extra packages for the repo
> > 14 - once there is a large repo of apps available, start the next cycle=
 at
> step 1
> >
> > Let me know what you all think.  Having this process more organized and
> coordinated will allow us to work quicker and more efficiently giving us
> more time to create the extra app repo that is needed to take VL to the n=
ext
> level. That way when Robert becomes rich from VL, he will share with all =
of
> us - lol.
> >
> > Regards,
> >
> > Tony
> >
>
>