[csw-maintainers] Ongoing projects

[Maciej Bliziński]

2011/8/23 Peter Bonivart <bonivart at opencsw.org>:
>> As a project, we'll be better off if we focus on one project at a time
>> and get it finished, meaning, completed enough to be pushed out to the
>> world.  This way, we deliver to our users.
>
> I've been pushing that view to several of you for a long time, glad to
> see someone else supporting it. It's obvious, both by your long list
> above and by the almost two month long interruption in package
> release, that we add tasks quicker than we complete them. Maybe we
> should have some cap on how many tasks we have going at once?

Yes.  There's one more thing to look at: who is contributing to
projects.  If we say that we work on 1 project, we need to make sure
that all maintainers can contribute to that project.  I imagine that
Dagobert is able to work on pretty much any project you can think of.
That doesn't have to be true for other people.  So if we only focus on
getting more people involved in the works, we would get a big boost,
regardless to whether we cap the number of projects or not.

> Another problem is the size of the tasks and how they tend to grow.
> Perl is one example where the last step of 64 bit is holding
> everything up, we have open bugs and an obsolete version of Perl, I
> think we should have fixed those issues and then continued on with 64
> bit after that. Divide the tasks into steps that the users can benefit
> from.

Yes, and it's best if someone pays attention to that and suggests how
to divide ongoing projects into parts.

> If I'm correct the release process task was previously stuck on
> signing the catalogs, then on notifying someone when the signing
> process stopped and now it has sucked in the package browser on the
> web site and Mantis integration into its black hole. :) I'm wondering
> if this couldn't have been done in steps so users could have gotten
> updates by now? Was this discussed on the list or only between those
> involved?

It's blocking on generating the new key and deploying it on cswsign.
I'm talking to Ihsan about it, I think he has the key ready, and we
need to escrow it, the way we decided in a vote some time ago.

> I'm fine with people actually doing the work having more say
> but by making stuff complex you also exclude people.

I agree that keeping things simple is beneficial.  However, there are
cases where it's impossible to keep things simple and be able to do
advanced tasks at the same time.  Usually, we try to decouple
functionality into smaller and easier to understand modules.  For
example, checkpkg is complex at places, but writing a single check is
easy: you get a data structure, you pull out the list or dict you
want, you look at the data that interests you and you call a function
to report an error. It doesn't get simpler than that, at least I can't
think of a simpler way to do it, given how complex are the packages
themselves.

Perhaps it's the matter of documentation and encouragement?  If you
have any ideas how to make things easier for people to get involved,
please share.

Maciej