On Wed, 7 Apr 2010 21:27:30 +0100 Graham Cobb <g+...@cobb.uk.net> wrote:
> On Wednesday 07 April 2010 16:54:28 Niels Breet wrote: > > On Wed, April 7, 2010 16:41, Andrew Flegg wrote: > > > On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs <n...@landwarsin.asia> > > > wrote: > > >> It seems to me that the real problem is actually the difficulty > > >> in implementing #4 above. If there were magically separate > > >> infrastructure for each incompatible release, there would be no > > >> issue - a developer uploads their package to each repository for > > >> which it builds (preferably through a list of checkboxes in the > > >> web interface), and a user selects one or more package sources > > >> that match the preinstalled software on their device. No > > >> problems, mate. > > > > > > True; however what about the QA process? The UI at > > > http://maemo.org/packages/ is getting better, but it's also > > > getting more familiar. How do we: > > > > > > a) not confuse ad-hoc testers b) ensure that versions in all > > > repos get tested? > > > > This is a non-trivial issue. Testing against all repos is not going > > to work, imagine what happens when we have PR1.2+1 etc. > > I agree. There is little point in having repositories for old > versions if nothing can ever get promoted into them because there are > very few testers left. Unless they are really intended just to be > archives: they work while the new version is being introduced (like > where we are at at the moment with PR1.2) but once the new version > has been out a few weeks, they just drop into archive mode with no > promotions, just an archive of software for the old version. You want to keep the repositories for exactly that reason. People can keep using their devices with no disruption of service. I, at least, feel that having the latest version of an application is secondary to avoiding a backwards leap in functionality. > > > One suggestion would be to promote all versions simultaneously, > > > but there are obvious drawbacks with that! > > > > That would make the most recent repo the best supported and tested > > repo. Older repos might or might not work. But then again, that is > > what -devel is now too. > > Actually I would make the process "make all versions eligible for > promotion simultaneously" -- once the latest version is tested the > developer can promote the other versions without QA when they wish > but they can choose to do some more testing themselves if they wish. That sounds decent to me. And it would help keep old/extras as up-to-date as new/extras. > In an earlier discussion I had proposed another alternative: have a > single repository but multiple autobuilders feeding it. I could > submit to either the PR1.1 or PR1.2 autobuilder but the output would > go into a single place. This seems more efficient than the "build > with PR1.1 and if that fails try PR1.2" option but otherwise quite > similar. > > The only problem I have noticed so far with that would come when you > introduced a new version which made use of some PR1.2 feature, and > hence was built with PR1.2. At that time, the PR1.1 version would no > longer be installable (as it has a lower version number and is in the > same repository). But for cases like this, where PR1.2 is expected to > be fairly quickly adopted once it is eventually released, this would > probably work well enough. > This is the only solution proposed so far which I would reject out of hand. It's what we've got right now, more or less. As a developer, this is fine - I can use PR1.2 packages. As a user, this is a nightmare. My applications disappear forever for reasons that are unclear to me. When I contact a developer, they say "wait for the PR1.2 release to come out". When I ask Nokia, they say "We do not discuss release dates for future firmware updates". It's better than the current situation in that packages not using 1.2 functionality aren't broken, but it's still not optimal and I feel it should be avoided at all costs. Remember, you also break packages DEPENDING on the ones using 1.2 functionality. The disruption could be very large if, say, Nokia were to update glibc. > Graham > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers
signature.asc
Description: PGP signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
