email address, and I am now using a new one here.
On 01/06/2017 07:21 AM, Pirate Praveen wrote:
> I have asked them to push their work to git.fosscommunity.in and send
> RFS mails to this list. Those who institute such bureaucracy should also
> volunteer to import these repos to alioth. I do not want to be forced to
> do extra work.
> Other option would have been using mentors.debian.net, but we lose the
> ability to incorporate their git history (or like now depend on external
> I will also look at possibility of using personal alioth repositories.
I really like to encourage the use of mentors.debian.net to new-comers.
There are a lot of experienced developers there who can answer general
packaging questions and queries about Debian policy etc. I have had
requests for help from people that would prefer to be mentored
privately. But I prefer that we all share our learning experiences on a
public list, so that others can learn at the same time. Mentors.net also
has the advantage that the package is known to have been successfully
built, in order for the *.changes file to get uploaded. It also gives
experience in debsign & dput.
But this thread points out that we are missing a parallel "mentors"
git/svn repository where people can learn about packaging within a
repository as well. The work can be pushed to the official place later
(whenever the sponsor suggests the mentee joins a team).
alioth repository (ie. join the team), my opinion is that the repository
is not the archive. We can always reconstruct the repo from the archive
(although losing some history) after discovering someone from the team
has misbehaved, or made a mistake. Commitment to continued maintenance
is something the sponsor should check before uploading to the archive. I
am sure there are a few sponsors that have been left "holding a baby"
when someone just wanted to get a package into Debian, but was lying
about their commitment. And this is not even after a "packaging
tutorial" or whatever event. The package will be orphaned and hopefully
picked up by someone else if it is an important enough package.
Other teams I am a member of, expect the "joining request" to include a
statement that they have read the team policy. Maybe we should add a
"softly" states that it is recommended to read the team policy before
applying to join? If the request to join is a little short on
information, you can always recommend they read the information (on the
list) after the request to join is accepted by someone in the team. I
have seen Jonas do this many times.