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

[Ken VanDine]

We need to brainstorm the process a bit, but I invision something like 3 labels:

foresight.rpath.org at fl:2-devel
foresight.rpath.org at fl:2-qa
foresight.rpath.org at fl:2

This doesn't address contrib at all, just stuff in the distro.

We will do our development on 2-devel, and developers will run
2-devel.  If possible we will maintain 2-qa boxes for testing.  Have a
designated pool of official testers that run prisinte 2-qa boxes for
testing.  As developers feel the work on 2-devel is ready (passed
developer testing), one of a few designed people will promote that
work to 2-qa and cook the group.  The testers should be automatically
updating, or get some way to be notified to update.  We also need some
way to track what has changed and what needs testing.  Those testers
report status, and when all tests pass we promote the entire cooked
group to fl:2 for the real world to consume.  We can do that with a
single command.

--Ken

On 4/22/07, Paul Cutler <pcutler at foresightlinux.org> wrote:
> Ken, for those of new to the role of packaging and testing, how does
> the process work today, versus what you want it to be in the future?
> Is it as easy as switching to the devel version of Foresight and
> reporting bugs?  What kind of turnaround timing are you looking for
> when a package is contributed to be tested and feedback received,
> before it's added to contrib or the repository?
>
> All I know is folks who do packaging create their own repo, and then a
> developer can add it to contrib.
>
> The reason I ask the questions above, is I would be more than happy to
> help frame and build the process if you'd like help, starting on the
> wiki.  I also have two extra computers I would be happy to test on as
> we figure out the process.
>
> Paul
>
> On 4/22/07, Ken VanDine <ken at vandine.org> wrote:
> > Even running 1-devel, my laptop has only really broken once in well
> > over a year.  It has always been usable, never got in the way of
> > work... although sometimes my ipod didn't work :)
> >
> > We could flag certain versions as being well known to work, and
> > provide a way in the gui to update to those.  I wouldn't want to use a
> > different group or repo.  That just complicates things.
> >
> > Perhaps a rss feed that lists well test, well known versions of
> > group-dist.  Then parse that feed with the gui and provide a way to
> > update between those versions.
> >
> > Either way, I really do want a more formal QA process and official
> > testers.  Give the testers hostmasks on freenode, email address,
> > etc... some perks for following and helping with the process.
> >
> > --Ken
> >
> > On 4/22/07, Thilo Pfennig <thilopfennig at foresightlinux.org> wrote:
> > > On 4/22/07, Ken VanDine <ken at vandine.org> wrote:
> > >
> > > > As opposed to forking, I would like to improve the QA process to make
> > > > things more stable.  We really just need more testers and a process.
> > > > Slowing down updates is not the right thing to do.  That just means
> > > > our hardware support gets worse.  Things like hal, udev, and the
> > > > kernel need to keep moving forward.  With each new release the range
> > > > of supported hardware grows.
> > >
> > > I think there is a certain group of users who like to have what they
> > > got without loosing any support or functionality that they got. I must
> > > admit that as I grow older I love that, too. Nontheless a new GNOME
> > > release always exites me also and I want to check it out.
> > >
> > > But I would like people to be able to have:
> > >
> > > 1) A stable, productional Desktop that rarely breaks (so a bit like
> > > like Debian stables fame) Here you do all your business work and you
> > > dont care a damn about new hardware support. I imagine this to be
> > > always updated and one would just do a snapshot once in a while that
> > > just reflects the current status. So maybe this means every three
> > > months a planned snapshot.
> > >
> > > 2) The always new system where you can always check out new things
> > > like new hardware and weird desktop magic.
> > >
> > >
> > > Ubuntu does this by switching from bleeding edge to a stable release
> > > on every release/hald year. i think that this is very bad because that
> > > means:
> > >  * You will only get a stable new desktop once a year
> > >  * You will only get newest tech once a year
> > >
> > > So this way we should not go.
> > >
> > > Debian does "its ready when its ready". This means that
> > >  * You will always get outdated software.
> > >  * You will habe to work with software that all upstream maintainers
> > > will not support. Like GNOME 2.14
> > >
> > > Thats also no way for us.
> > >
> > > Fedora likes to do a half year release cycle and also wants to be near
> > > to GNOME. But they are very much into meritocracy. We want to be more
> > > democratic also in packaging.
> > >
> > >
> > > Thilo
> > >
> > > --
> > > Thilo Pfennig
> > > http://issues.foresightlinux.org/confluence/x/R
> > >
> > _______________________________________________
> > Foresight-devel mailing list
> > Foresight-devel at lists.rpath.org
> > http://lists.rpath.org/mailman/listinfo/foresight-devel
> >
>