Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, 12 Nov 2014, Raphael Hertzog wrote:
> On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
> > In fact, I was quite non-amused by the initial versions of this idea, but
> > reading this latest version, I must say I *like* it. Well done! I am
> > especially happy about the way it respects the usual git usage conventions,
> > this will ease its adoption a lot.
>
> Thank you! I'm pleased to see that I managed to draft something reasonable.
>
> > It does fail to mention security, and stable-proposed branches. We can just
> > leave those to maintainer's discretion, of course.
>
> I believe that those are not really needed in most cases. You rarely have
> conflicting updates for -security and -proposed-updates at the same time.
> But of course we can say something along this:
>
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -73,6 +73,14 @@ target distribution. In the case of Debian, that means for example
> "suite" names because those tend to evolve over time ("stable" becomes
> "oldstable" and so on).
>
> +Security updates and stable updates are expected to be handled on
> +the branch of the associated distribution. For example, in the case of
> +Debian, uploads to `wheezy-security` or `wheezy-proposed-updates`
> +are prepared on the `debian/wheezy` branch. Shall there be a need to
> +manage different versions of the packages in both repositories, then
> +the branches `debian/wheezy-security` and `debian/wheezy-updates`
> +can be used.
> +
> The Git repository listed in debian/control's `Vcs-Git` field should
> usually have its HEAD point to the branch corresponding to the
> distribution where new upstream versions are usually sent. For Debian,
>
>
> How does that sound ?
Well, I use a stable-proposed branch because it might well happen that the
stable update is rejected. As for -security updates, they can be superseded
by -stable updates.
So, it all depends on how well you are going to deal with the need to rebase
or revert. I'd be very wary to push for a specific workflow that forces
anyone to rebase or revert, even if it is not something that will happen
often.
So, I sugest we either leave this to maintainer's discretion, or go with the
use of separate <vendor>/<release>-* branches for s-p-u and security.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: