[Pkg-javascript-devel] Feasibility of GitLab as a Debian package (was: Heads up: Likely scaling back on my involvement in JavaScript team)

[Pirate Praveen]

On 12/28/18 10:58 AM, Ben Finney wrote:
> Pirate Praveen <praveen at onenetbeyond.org> writes:
> 
>> I started getting involved in JavaScript team to keep diaspora and
>> gitlab packages in main.
> 
> (I am very grateful to your work, not only in package maintenance but
> also in providing a focus for the work of many others in the JavaScript
> team.)

Thanks.

>> Gitlab was included in stretch but it is proposed to be removed from
>> buster. [1]
> 
> An exchange from that bug report discussion:
> 
>     Pirate Praveen:
>     > [I am trying to find] other ways to accommodate fast changing
>     > software like gitlab. Broadening the definition of backports is
>     > one possible option I see. Another option could be to have
>     > personal package archive for gitlab.
> 
>     Thorsten Glaser:
>     > Find a way to pick stable, slow changing versions of it and
>     > improve their packaging in testing/unstable so you can backport
>     > it.
>     >
>     > Work with upstream towards that goal. Some upstreams are receptive
>     > of stabilising certain versions in order to get packaged.
>     >
>     > If [the ‘gitlab’ package] upstreams aren’t, they’re probably not
>     > worth the effort using the software.
> 
> Pirate, to what extent do you agree with Thorsten's assessment?

I think that is just living in denial. I think it was pointed out by
many how silly that argument is because debian itself is using gitlab as
a core component of its development infrastructure. So I don't think the
pace of development has nothing to do with whether a software is useful
or not.

> How broadly does this apply to JavaScript software, or how narrowly is
> this applicable to only GitLab? Or some other extent?

This is specific to gitlab. It uses a large number of node/javascript
modules and if there is no official gitlab package in debian, then there
is no motivation to keep packaging them. If gitlab itself need to be
obtained from an unofficial repo, then it should be fine to get these
node modules from npmjs.com as well.

>> I proposed a redefined volatile archive that can accommodate packages
>> like gitlab. I hope it gets accepted.
> 
> Dominik George mentions (also in that bug report discussion) he hopes to
> bring a propsed redefinition also. I hope that this can be a help to
> package maintainers.

I hope too, this proposal can go through.

> My concern, though, is that GitLab is just one example of the JavaScript
> developer community being particularly hostile – more than merely
> uninterested, but actively working to fight against – long-term stable
> releases with ongoing maintenance. GitLab is an example of this, and I
> wonder to what extent this is true for *most* JavaScript software that
> we would like available as Debian packages.

There is a difficulty in packaging javascript/node packages in general,
but this particular situation is specific to gitlab as a single project.
Each of those node modules could be included in stable and hence in
backports.

> If that is true, I think moving such software into a special
> low-stability, short-term-maintenance section is not part of a solution,
> only covering up a problem that needs to be fixed by working with
> upstream to improve release and maintenance practices.
> 

I think its too naive to think only our development model is right and
we can convert everyone else.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20181229/37cebee4/attachment.sig>