[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking for Upstream mentorship



On Sat, Jun 28, 2014 at 11:54 PM, adrian15 wrote:

> This message might be offtopic depending on derivate people being also
> upstream of their own software package or not.

That is a relatively common scenario.

> I have found a debian-upstream mailing list (
> https://lists.debian.org/debian-upstream/ ) but I have choosen not to write
> there because there is not many traffic on it (seems dead).

It isn't dead but people see that there has been no mail, think it is
dead and post on the wrong list instead of the right list, which leads
to even less mail in a recurring cycle :)

Anyway, some thoughts in response to your mail:

Sponsorship (checking and uploading packages) and mentorship (teaching
people packaging) are two different things, both happen on the
debian-mentors list and mentors.debian.net infrastructure and are
intertwined.

In practice we get a lot of people packaging software they maintain or
wrote; that usually results in some discussion of upstream development
practices on debian-mentors. Rarely is there any discussion of
upstream development practices not in connection with any specific
packaging effort though.

The external advice section of the Upstream Guide contains lots more
useful information about how to run a successful FLOSS project, please
do read through it:

https://wiki.debian.org/UpstreamGuide#External_advice

I think a central place for general FLOSS mentoring would be
interesting but hard to achieve; the FLOSS world is very technically
and socially diverse. Right now the best place to get mentoring is the
IRC channels and mailing lists of the technologies that your questions
are about. Getting people to join a general mentoring group will be
hard because many of the questions will be about things they don't
know about and they won't want to deal with the extra noise. That
said, maybe stackoverflow is the right place to ask such questions. It
isn't limited to FLOSS stuff though.

I also can't resist answering your questions:

>   5.1) Rescapp, my main program, is based on Python. Currently it adds
> dinamically rescue-targeted scripts to a self-building pyqt menu. What's the
> advised way of dealing with plugins in Python? And what about PyQT?

That sounds like a question for the Python upstream community.

>   5.2) Current Rescatux, which it's a distro, source code contains Rescapp
> source code in it as is. Am I supposed to keep a separated GIT repo for each
> one of the applications in my distro ? How do I handle each of them as if
> they were one GIT repo to ease development?

That would be up to you. Personally I would have a separate repository
for each application. My favourite tool for managing multiple
repositories (git/svn/hg/darcs/cvs/etc) is myrepos. Another one is
git-repo, which is used by Android developers.

https://packages.debian.org/sid/myrepos
https://code.google.com/p/git-repo/

>   5.3) Is there any script for checking every script and their copyright and
> add to them a default copyright based on GPLv3 and my name?

There is no substitute for manually checking the history of the
project and tracking the copyright holder of the contributions. The
licensecheck2dep5 tool from the Debian cdbs package might be helpful
to aggregate existing copyright and license information into one file.
In general it is best to have per-file license/copyright info anyway.

http://lu.is/blog/2012/03/17/on-the-importance-of-per-file-license-information/

>   5.4) Rescapp, currently lives at the Debian live desktop user directory
> and it's path is hardcoded. How do python programs deal with hard coded
> paths usually?

In general, don't use hard-coded paths, allow paths to be different at
runtime or build time.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


Reply to: