[Foresight-devel] Re: Two flavors of FL?

Mon Apr 23 21:21:17 EDT 2007

Well in regard to the speed issue, in the next release on conary
support to pull from svn repos will be included so then we could be
running svn snapshots in 2-devel and then once a program is released
package the new release and then pass it on to qa.  IIRC the thing
that slows debian down is they don't do testing along the route only
when it is officialy released.  This method would keep us on top when
programs released since ideally a program would be pushed to qa on its
released day and then qa would test it for a determined period and
pass to fl:2

Kevin

On 4/23/07, Cesar Cardoso <listas at zyakannazio.eti.br> wrote:
> Looks like a good scheme, with @2-contrib for contributed packages (and
> so being a good warn to users that these packages aren't in the same
> releng/QA scheme of the main distro).
>
> My only worry is about the speed of the QA process; remember that Debian
>   uses this scheme, but IRL it slowed their process. Sure Conary helps
> us A LOT in terms of having a quick and safe QA process :)
>
> Paul Scott-Wilson wrote:
> > On Mon, Apr 23, 2007 at 12:09:27AM -0400, Ken VanDine wrote:
> >> We need to brainstorm the process a bit, but I invision something like
> >> 3 labels:
> >>
> >> foresight.rpath.org at fl:2-devel qa
> >> foresight.rpath.org at fl:2
> >>
> >> This doesn't address contrib at all, just stuff in the distro.
> > Sounds like a good plan to me; reminds me of the current-stable-release I'm
> > familiar with on Freebsd. Having proper release engineering for the foresight
> > repo is preferable than maintain a separate project outside it. Not that having
> > a separate project is a bad idea, I've been meaning to do something similar
> > with Asylum just so I can get an idea of whats involved.
> >
> > The devel-qa-release structure means we can do the continuous integration we
> > need on devel. Users that want the trickle of constant updates (at the price of
> > occasional breakages) can get them from qa and users that want scheduled update
> > of "stable" changes can get them from release. The problem with the current
> > releng is even though changes are made to :1-devel most of us are running :1
> > so packages transition between the two quicker than they ought to. This means
> > that all users get all to familiar "33 Updates" - 1 package update and all the
> > groups. This gives the impression that no quality assurance is happening at
> > all, things just get updated when they are available.
> >
> > My view of packages is skewed some what because I'm a long time user of BSD. In
> > my eyes the OS is made up of two parts. The base - 99% of which is rPath Linux
> > 1 - and third party packages. Except when rogue packages appear from rpl:devel
> > Foresight _is_ stable. The continuous update of packages is important because
> > _all_ packages come from a third party. If they release a new stable version
> > we have an obligation to use it; if its turns out not to be we should let them
> > know. With better releng those packages can live on devel and qa so release
> > users aren't affected.
> >
> > In my opinion long term support for a release is something we should leave
> > until we have a really solid release and more developers. Backporting fixes to
> > older packages isn't my idea of fun or stable software. For the moment I think
> > signing off on group versions we consider stable is the way to go - since we
> > get snapshotting of package versions for free at least for groups. I thought we
> > might be able to do this with the gpg signing in conary by only signing known
> > good groups and conary would only update to signed groups. Seems thats not how
> > it works though.
> >
> > On Mon, Apr 23, 2007 at 10:53:16AM +0200, Thilo Pfennig wrote:
> >> I think it does not make sense to have a contrib-devel and -qa also.
> >> Maybe better have just:
> >>
> >>  + foresight.rpath.org at fl:2-contrib
> > I disagree. I think that all packages, base and contrib, should follow the same
> > releng path. All package commits should be to devel, tested in qa and end up
> > in the release branch. This removes the distinction between base packages and
> > contributed packages so packages are free to be swapped between the two. For
> > example, if we wanted to replace glipper for Paracelle in Foresight we could do
> > it just by updating the group recipe. It wouldn't need to be shadowed/promoted
> > to a different branch.
> >
> > The main difference is that "blessed" packages that are part of the base
> > install should only be shadowed/promoted to the release branch (and perhaps the
> > qa branch) by the head chef or sous chefs. Contributed packages can be updated
> > by the rest of us line cooks.
> >
> > On a side note, I'm notice a few misuses of conary terms by us non rpathians.
> > We should probably be more careful not to mix up repos, branches, namespace,
> > labels and flavors. On the flip side they are using terms that may not be
> > obvious to us - I had to go lookup what promote actually did since last time I
> > checked it wasn't documented.
> >
> > In the following question I don't always mean repo and branch in the conary
> > sense.
> >
> > I've recently been playing with hal and friends to get ntfs magically working.
> > After updating a few packages and writing a few we didn't have its at the point
> > where it will 'just work' with a new version of hal. The caveat being it'll
> > currently probably break everyones ipods. While doing that I took the chance
> > to play around with git which uses branches similarly to hg except they live
> > in the same repo. When your working on a new feature you normally create a
> > 'feature branch', make some changes and then merge those changes back into
> > the master branch. This got me thinking about whether something similar was
> > possible in a conary context. Obviously I wouldn't want to do it in the main
> > repo (or any long living repo for that matter). It would be useful if I could
> > create a "branch" in a local repo and make that available for others to try.
> > The three obvious ways to share changes are throwing around changesets, publish
> > rmakes repo or setup a proper repo. Is anyone doing this and is there a better
> > way?
> >
> > --
> > Paul.
> > _______________________________________________
> > Foresight-devel mailing list
> > Foresight-devel at lists.rpath.org
> > http://lists.rpath.org/mailman/listinfo/foresight-devel
>
>
> --
> cesar em cesarcardoso tk ou cesar em zyakannazio eti br
> "O ser humano faz as coisas para tornar sua vida mais confortável, mas
> acaba tornando desconfortável" (Cleber Machado)
> _______________________________________________
> Foresight-devel mailing list
> Foresight-devel at lists.rpath.org
> http://lists.rpath.org/mailman/listinfo/foresight-devel
>

-- 
- specialKevin
- Kevin Harriss
- http://www.specialkevin.com