On Wed, 7 Apr 2010 15:41:48 +0100 Andrew Flegg <and...@bleb.org> 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? > Each QA tester (probably) only uses one device for testing. If this is true, this means that applications get tested on the platform the QA testers are on. This doesn't guarantee coverage for any particular application/SDK combination, but it does mean that things that are important to (the QA) users will get more throughly used. I'm not convinced that's a bad thing. As long as the QA users make both positive and negative bug reports, I think this will probably work out while not totally satisfying (b) above. (a) is OK because each QA tester just uses the repos matching their device, and upgrades whenever the next level meets their own personal comfort level with the bleeding-edge-to-stability spectrum. > One suggestion would be to promote all versions simultaneously, but > there are obvious drawbacks with that! I wouldn't do that. I'd promote things when you have enough negative bug reports about the particular version. Some things will never get promoted if nobody loves them. Tough cookies - if nobody cares enough to test the package as it is, does it really need promotion? > > So the real issue is that creating a new branch requires a > > nontrivial amount of work. This is a computerized system; > > computers excel at automation. Why not spend the one-off time to > > allow for near-instant creation of a new branch? Once that's done, > > future releases will just consist of "oh, I should create a new > > repository for this release. Let me run that script again with a > > new name and then upload the new SDK release to it". > > Indeed. > > > Have I missed some important consideration? > > I think the issues aren't technical (although streamlining the repo > creation is obviously part of it), but more procedural. I could be > wrong. I wonder what the testing squad think (I'll poke VDVsx). I can't really say anything about whatever internal rules would restrict this from working. I obviously have an interest in the process working better than it has, so I felt like commenting. It would be a shame if it were more than a technical problem. It's easier to argue for longer about qualitative things. > Cheers, > > Andrew > Bryan Jacobs
signature.asc
Description: PGP signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
