launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

2009/7/29 Michael Nelson <michael.nelson@xxxxxxxxxxxxx>:

>> You're right that the PPA serves two audiences and is pretty busy at
>> the moment.  But it's also the case that many PPA publishers are going
>> to be fairly new to making packages so may not want a
>> debian-archive-expert-oriented view.
>
> Specifically which aspects of the mockup do you think are
> debian-archive-expert-oriented? (I feel exactly the same way and was
> trying to ensure it was welcoming to new PPA publishers).

Nothing in your mockup; this was in response to the comment on splitting it.

>  For them, the PPA web page
>> provides important intellectual and emotional confirmation that they
>> have actually done what they intended to do.
>
> So, if I'm understanding you correctly, you are saying that it is not
> enough that they can view currently building packages etc. at
> +ppa/my_ppa/packages to see that info but it should be part of their PPA
> summary - yes, good point.

I'm not sure if it needs to including things building or waiting to
build, but a view of recently changed packages would be good.

I think you also need to somehow convey a bit more strongly that there
are two views: what's currently in the archive (which changes over
time); and things trying to get into the archive (including the queue,
failed builds, etc.)  But this is probably less urgent than the main
view.


>> Rather than just the signing key ID I'd suggest you actually give the
>> command necessary to add it.  There's a big question here about
>> whether you should encourage people to copy and paste random sudo
>> commands or how to confirm informed consent, but I believe that just
>> making it complicated doesn't really help.
>
> Did you notice that with Karmic you won't need to do that? That is, mvo
> has done the work so that we can just add 'ppa:username/ppaname' to
> software sources and it automatically imports the key? But sure, we
> could include the sudo command in the 'Technical details about this PPA'
> drop-down (which should be perhaps 'Manual instructions for adding this
> PPA' or something similar.

I didn't know that.  It is pretty cool.

>

>> I think showing the full list of packages is useful because it gives a
>> sense of whether the ppa really aligns with its purpose or whether
>> it's just a random dumping ground as some of the early ones were.
>
> Hmm... while I think the list of packages should stay there at the
> bottom for the moment (I'll include it in the next mock), I am hoping
> that we can find a better way to communicate the scope of the PPA
> without so much detail. Something like:
>
> For ppas with <= 5 packages:
> This PPA will currently only update the following packages on your system:
>  * one
>  * ..
>
> For ppas with > 5 packages, we'd just refer to the complete table.
>
> Off topic, but it would be *great* to be able to say "This PPA only
> updates the following packages on your system (you will be notified if
> further packages are added in the future)." - ie. have some concept of
> PPA scope built into PPAs and controlled by owners.

That would be nice.  I think phrasing like "will currently only
update" is inappropriate until you actually add this feature...


-- 
Martin <http://launchpad.net/~mbp/>