Hello.
On Wed, 2009-07-29 at 14:15, Klaus 'mrmoku' Kurzmann wrote:
> Am Mittwoch 29 Juli 2009 14:00:06 schrieb Stefan Schmidt:
> >
> > On Thu, 2009-07-23 at 19:04, Klaus 'mrmoku' Kurzmann wrote:
> > >
> > > how do we continue now? Base a new branch upon oe.dev and merge in stuff
> > > from ms5.5 and shr/import as we need it? Or start with ms5.5 or
> > > shr/import and merge stuff into oe.dev?
> >
> > May I ask for a short summary of what you discussed at FSOSHRUDCON? I have
> > soem thoughts about some aspects for a stable distro, but I would like to
> > base them on what you already discussed.
> AFAIR (and that is not much, because my memory sucks ;) basically it was to
> have a common branch in OE for all the smartphone distros.
Well, I expected a bit more. ;)
So here is my perspective on the distro thing. This is a _proposal_. I always
respect the decision from people doing the actual work, SHR distro guys I look
at you. I'm sure Mickey, Daniel, Jan and myself will commit fixes, new recipes,
etc from time to time, but we hope to get rid of the day-by-day work.
Action Items:
-------------
1) Check if fso/milestone5.5 has anything that is missing in shr/import, if yes,
merge it into shr/import
2) Make a list of commits that are in shr/import but not in .dev.
3) Categorize these commits:
- Can go directly into .dev (Should be ok for most changes in the fso and
vala recipes)
- Already fixed in .dev in such or another way. Drop it.
- Distro/Machine/Whatever hack. Discuss, can stay in a shr branch if to
problematic.
- Uncertain. Bring them up here and we will discuss them.
4) Cherry-pick all good commits into .dev, make sure they build and work.
5) Start shr/unstable from this buildable point in .dev
6) Cherry-pick oustanding chances from shr/import
7) Build all images from shr/unstable
That's what I think we need to do right now. I would aim a deadline like 1.9 for
all of them. Once that is done we can go further to think about how a stable
distro model should work for us. Something along these lines would make sense
imho. (You are doing a lot like this already, but this is a bit more formalized)
- Starting from a working shr/unstable branch we branch of to shr/testing from
it. From that point we have strict rules for commits to shr/stable:
- ALL commits in stable are comming from shr/unstable. That means every commit
gets there first and after some testing gets cherry-picked into shr/testing.
Exception for this rule.
- A commit only gets cherry picked if it builds, is installable and was
tested.
- If a commit brings a regression it get's reverted. Period.
- Once testing is in shape for a release and we want to release we branch of
from shr/testing into shr/stable-$(version)
- I'm undecided how we should handle maintainance for the stable branch wrt
commits in testing and unstable.
- I also have no idea at what point you guys want to release. Personally I'm in
favour of time based releases with a window around it. MS5.5 aside that worked
not to bad for FSO. It would also make sense to time a SHR release shortly
after a FSO milestone?
A lot of details and pitfalls missing still I would like to give this a kick-off
and bring in my thoughts. The unstable/testing/stable, stolen from debian, was
also used for the OM2008 distro and I think that this scheme worked pretty well
from a distro point of view. If you guys are in favour of it I would ask zecke
for details how he managed it.
regards
Stefan Schmidt
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
