[Dev] a project manager for parabola?

[Nicolás Reynolds]

On Mon, 06 Feb 2012 20:44:00 +0100, mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=) wrote:
> > a few days ago i installed chili[0] for our local hacklab project
> > management. i was thinking it would be useful for parabola, not only as
> > an issue tracker[1] but also as whole project manager for the community,
> > if we organize "workflows" on a democratic fashion.
> 
> Which specific problems can it solve more easily than our separate issue
> tracker, lists, git repos and wiki?

in my experience, mailing lists are good for communication and
discussion but not to keep track of this getting done, sharing workload
and etc. my idea is to automatize the organization method without having
a person greatly dedicated to it or discuss something and then loose it
on the thread history.

> > for instance guys at the irc channel are talking about working on a hurd
> > port, on chili it would be a matter of creating a new project for it.
> 
> The mips64el port has a separate (unpopular) mailing list, separate git
> repo (although some changes aren't done there), otherwise all resources
> are shared with other ports.  I don't see how having it separated would
> be easier (unless we get too many mails/bugs to read all of them).

i meant it as an easy to spot way of knowing what projects are being
carried on. issue trackers can be shared between projects also (or
projects have several issue trackers...)

> > [1]: there're some glitches with our current bug tracker
> 
> Which ones?  Will they be fixed by replacing the tracker?
> 
> Having two separate trackers "living" at once is a bad solution, so we
> would need to migrate the existing one.  Can this be done easily
> (i.e. by running a single script which can be easily tested) preserving
> its whole history?  (This would avoid the difficulties with wiki
> migration.)

both run on postgresql so a couple querys can be crafted to migrate over.

> I know the following problems with our current tracker:

this are the glitches i was refering to

> 
> - I don't know how to state there that a bug is a duplicate or
>   [reverse-]dependency of another bug (i.e. it's not obvious, not
>   documented or too different from other trackers)

this is simple, you can issue sub reports (which give you a progress bar
on the parent issue) and state relationships between reports.

> 
> - probably easy to fix problems with mail/IRC notifications

atom and email notifications :)

> 
> - it uses different names for some metadata than most other trackers
>   known to me (it's a problem, since tracker's use being difficult for
>   users of other trackers will lead to unreported bugs)

this can be setup on both projects, just that roundup requires that you
do it during setting it up and know python. chili has an administration
panel where issue statuses can be created.

> 
> - our bug workflow is more complex than currently stated, e.g.:
> 
>                                  /> i686 building     -> testing \
>   unread -> chatting -> patching -> x86_64 building   -> testing  > resolved
>                                  \> mips64el building -> testing /
> 
>   in case of KDE-related or texlive-bin-libre bugs.
>   (We have different sets of builders for each arch, notifying them and
>   formally marking that it's being done could make this process easier.)

it could be put on three different sub-issues assigned to the
architecture specific group of packagers or something like that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120206/3f38faf8/attachment.sig>