Re: [Debconf-discuss] Summit discussion on Thursday, 11:00am (18:00 UTC)
Hello Vorlon,
On 30.08.2014 09:47, Steve Langasek wrote:
> Hi Cate,
>
> On Wed, Aug 27, 2014 at 11:08:21AM +0200, Giacomo Catenazzi wrote:
>> We have some problem on sso, people some are registering with both
>> debian and alioth, which cause some confusion.
>> Could we link debian and alioth accounts?
>> Should we improve the login page?
>
> I had a hallway discussion with Enrico Zini about this here; he's interested
> in streamlining the SSO handling to address exactly this, normalizing so
> that Debian developers would always log in via Debian SSO and alioth would
> be used only for non-DDs.
>
> Implementing this thing we all agree on is left as an exercise for the
> relevant system maintainers.
Nice!
>
>> Maybe we should start again summit from upstream (and with some
>> discussion with upstream), so to make think more generalized (for all
>> debconf) and cleaner schema.
>
> I disagree. I think we should instead leverage django's top-notch schema
> migration support, to continue forward from our currently working deployment
> while normalizing for multiple DebConfs, and working with upstream to merge
> our schema extensions. This lets us carry forward our data intact in a
> retrievable fashion.
Note: I don't propose to trash the changes, but only to start from zero,
and correct the various patches (e.g. moving line, tables) (and than
importing things to the database).
Becuase it is the first dc on new database, it is easier to do it and
thus to have a clean version, instead of taking care of special cases in
future debconfs.
>> [ - On deployment a reference from attendee_id to user_id was lost
>
> I'm not sure what you mean here.
The reference between the two id is lost in the deployed version, so as
I told you on IRC, one person had attendee_id and not user_id.
>
>> - bursaries info are in different table need_food are never in the
>> same table as need_accommodation
>
> Yes; they're part of the same django class, which means that the table joins
> are transparent if you're using the ORM. Upstreaming our model extensions
> would certainly let us make this simpler for those doing SQL queries. (And
> upstreaming our model extensions would also let us better tailor the code in
> various places which I've avoided touching because they would require
> extensive changes to cope with our current subclassing.)
yeah, but doing again, we can put the three type of sponsorhip together,
which in long run is a win.
Not a big deal, but I find that summit as a lot of rough edges (e.g.
also non so consisted naming), which IMHO could now be fixed easily (and
maybe also upstream), simplify a lot the future development.
>> Roles are still confusing (and not so much used). We need to improve
>> this, so to delegate more.
>
> What other roles are you looking for here?
Note: Now we have a notion problem with front desk so maybe we should
rename the old front desk task.
But now registration is "admin", which is IMHO not so optimal.
We had some discussion about how to add and track payments.
IIRC I think scheduler and talk groups are not defined as previous
DebConf usage.
And IIRC video want to delegate again to talk team the talkmeister things.
But also the procedure. Who and how to add people to groups was not
clear to me.
Note: I wrote many "defects" but anyway summit is much much more useable
than penta (and apart of many "non arrived" people, we didn't have any
disappeared persons/fields/statuses as we had regularly in penta)
ciao
cate
Reply to: