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

[Tony B. <tb...@gm...>]

On 4/6/06, uel archuletta <ue...@gm...> wrote:

>
>
>  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. her=
e
> > > 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 =
upon
> > at the beginning and hand out the workload equally. Remember, in the pa=
st
> > 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=
 in
> > > 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 ar=
e
> 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.
>


I think this would create more work.  Apps built for SOHO would have
kde-centric additions wherever possible to integrate them better into the
desktop environment. While we may use the same apps for std, they should no=
t
have kde deps in them.  This is kind of like the issue you get if you try t=
o
install packages from linuxpackages.net - arts has a dep of gnome - wtf?
Whay would you build arts with a gnome dep. Same goes for apps for std that
might have a kde dep - not a good thing at all.

The base would be common to all, including X and dev.  std(WM's and
apps) and soho(KDE and apps) would then be built on top of the base.  Soho
would have KDE as its first build so that any other app installs after that
would be able to use kde hooks where needed.



>
>
>   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=
 it
> to the metapackage
>
>


I really don't think xfce should be in SOHO.  IMHO, 99% of those that get
SOHO are getting it for kde and not xfce.  If they want xfce, they should
stick with std.  This would also allow us to make soho easier and better du=
e
to the fact that you wouldn't have to worry about menus and such as long as
a kde .desktop file was included with the packages.
Folks that are looking for xfce aren't looking for the bloat of kde and
those looking for the richness and integration of kde aren't looking for
xfce.  Again, we need to go back and look at the target market for these an=
d
not what we want out of it.  We could always add wm's and such to the repo
but I doubt they'd get a lot of hits.

Concentrating only on kde for soho would be the best bet.  choosing apps fo=
r
soho should also be centred around kde as well so they integrate properly
into the DE.  The maturity of the apps for kde is there now and we should
take advantage of that.

The only folks I know that run SOHO with xfce are vec and monty - lol. No
offense guys.

We need to focus on packages as that is what is really important. That is
why stuff like ubuntu, gentoo,etc have gained the popularity they have.
Folks don't have to go searching a million different places to get what the=
y
need. It is all available from a central source for the most part.

Linuxpackages and slacky.it are ok but they still have some goofyness to
them with deps of stuff that isn't needed.



>    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 mad=
e
> > > > 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 correcte=
d for
> > > > arch,flags,etc
> > > > 3 - once the base is built, each developer is given a source tree o=
r
> > > > 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 fo=
r soho -
> > > > 2 groups are needed here - std and soho and there will be some dupl=
ication
> > > > as std and soho should be treated as separate distros - all build s=
cripts
> > > > 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 t=
here 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 package=
s
> > > > 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 =
giving us
> > > > more time to create the extra app repo that is needed to take VL to=
 the next
> > > > level. That way when Robert becomes rich from VL, he will share wit=
h all of
> > > > us - lol.
> > > >
> > > > Regards,
> > > >  Tony
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>