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

Re: [PATCH 00/12] Plannings for secure-testing repository migration to git



Hi Guido

Much appreciated you looked at the patchset!

On Wed, Dec 27, 2017 at 09:14:52PM +0100, Guido Günther wrote:
> Hi,
> On Wed, Dec 27, 2017 at 08:42:49PM +0100, Salvatore Bonaccorso wrote:
> > This *preliminary* patchset for review is for the changes needed after
> > we would switch from alioth to salsa for the secure-testing repository.
> > While needing to do the svn to git conversion the opportunity was taken
> > to rename the repository to security-tracker as the naming
> > secure-testing was for historical reason when the testing security
> > support arised.
> 
> This looks good! I applied your patches to my checkout I found some more
> svn references in
> 
> * tracker 'latest_revision' method

Jupp that was what I mean that I need here some insights from a LTS
member and how the script functions. 

> * website/uploading.html

That was intentional, because the uploading.html is mostly for
historic reference there when the secure-testing project arised. It is
about DTSA. We can change that but I though we could leave that site
as it is.

> * doc/soriano.txt (which needs to match what we do in
>   security-tracker-service I guess)

Yes that is pending, I waited for that part before
security-tracker-service are sorted out, so that the documentation
then can mirror how it's now then actually set up on soriano.

> * the security-tracker-service repo 

have that already :). But I'm unahappy with my current versions, thus
I have not sent those yet. Basically: I'm struggling with a proper
replacement of such constructs:

cd /srv/security-tracker.debian.org/website/secure-testing/data && svn update && ../bin/update && svn commit -qm "automatic update" CVE && cd CVE && ../../bin/bts-update list

> Should we create WiP/git-migration branches in the secure-testing and
> security-tracker-service repos so others can send in pull requests?
> 
> We could rebase the branch in the secure-testing repo from time to time
> so catch up with the changes in the svn repo.

Give me a bit of time to think about it. My intention was to not
clutter now what we have on salsa as mirror and constantly push
updates there. And once we go live, add the Debian group as allowed to
push, and block the original svn repository.  I would like to avoid
that people already start pushing to the git repository directly.

Or do you mean to still create the branches on the git repo on salsa
(accessible readonly, so that people can contribute based on that,
rather based on patch for pull requests? As said, I would like to not
operate directly on the git repo until the switch  to not cause
problems. Our live instance is currently still the svn repo).

I would expect we solve the open problems soonish enough so we can do
the switch. That is:

1/ desire of commit mailinglist
2/ how to do the updates with the sectracker role account specific to
some files (e.g. automatic updates, data/CVE/list update, dsa
canditate finding).

Thanks a lot for your contribution Guido!

Salvatore


Reply to: