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

[uel a. <ue...@gm...>]

On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> > Sounds good. I have some additions to a few of your propositions. here
> > thay are
> >
> > 1. we have some package list we may be able to use to help in this they
> > are in ftp in the VL6base folder.
> > 2. I nominate you to build the base and get it setup for us. :)
> >
>
> OK
>
>
>  3. sounds good, but do we have enough people to seperate into 2 groups?
> >
>
> If not 2 groups, then each dev can have 2 partitions for dev - std and
> soho. This shouldn't be too bad a task if we have all the pkgs decided up=
on
> at the beginning and hand out the workload equally. Remember, in the past
> Robert did std by himself and I did soho by myself on top of std so it is
> possible.
>

That is workable 2 seperate workloads if one has time/space they could work
on both.



4. agree
> > 5. agree
> > 6. I along with others would like to see this borken down further.
> > base-cli, dev, X, std, soho, some examples would be the package lists i=
n
> > VL6base on ftp.
> >
>
>
> base-cli and dev will have to be 1 since we can't work on a base without
> dev tools.
>

this is where I get things mixed up so correct me if I am wrong. if we are
building packages and populating a repo then we can build a base for the
devs to build packages on that has all tools and X, and then build a base
for the installer that has them seperated out. as long as we test the
packages on this base as well.




X - if by this you mean xorg alone then I agree but if this includes
> WM's,etc then no.
>

Vec asked if we couldnt include xfce in our xorg package since it is in
both, and if we go down to the package level it woould simply mean adding i=
t
to the metapackage


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
> > > aware of it so here goes.
> > >
> > > I have been looking at these as I'm sure some or all of you have as
> > > well.
> > >
> > > 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
> > > before we start
> > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > source 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
> > > trees and they work on those on top of the base(vlbase.tgz).eg.
> > > kde,xap,etc - all packages must be built on a virgin base except for =
soho -
> > > 2 groups are needed here - std and soho and there will be some duplic=
ation
> > > as std and soho should be treated as separate distros - all build scr=
ipts
> > > need to corrected for arch,flags,etc
> > > 4 - we need to come up with SlackBuilds for the packages we include
> > > that aren't in slack and split this up depending on how many pkgs the=
re are
> > > 5 - upload all the built packages to the respective trees and each of
> > > us 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
> > > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE
> > > only and have 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
> > > stable.
> > > 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 gi=
ving us
> > > more time to create the extra app repo that is needed to take VL to t=
he next
> > > level. That way when Robert becomes rich from VL, he will share with =
all of
> > > us - lol.
> > >
> > > Regards,
> > >  Tony
> > >
> > >
> >
> >
>