[maemo-developers] PR1.2 SDK for Extras-devel: how to solve?

From: Bryan Jacobs no at landwarsin.asia
Date: Wed Apr 7 17:58:51 EEST 2010
On Wed, 7 Apr 2010 15:41:48 +0100
Andrew Flegg <andrew at bleb.org> wrote:

> On Wed, Apr 7, 2010 at 15:13, Bryan Jacobs <no at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.maemo.org/pipermail/maemo-developers/attachments/20100407/9eedebb3/attachment.pgp>
More information about the maemo-developers mailing list